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ABSTRACT 


This  report  describes  CEL,  a  conversational  extensible 
language.  Its  syntax,  data,  control  structures  and  conversational 
features  are  presented  and  compared  to  those  of  other  languages. 
Its  use  is  illustrated  by  means  of  several  examples  in  the  areas  of 
list  processing,  polynomial  arithmetic,  formula  manipulation, 
vector  arithmetic,  trees  and  syntax  analysis,  complex  and 
rational  arithmetic  and  block  structure  and  own  variables. 
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SECTION  I 


Introduction 


In  November  1969  the  author  undertook  the  design  of  a 
conversational  extensible  language  and  the  implementation  of  that 
language  on  Harvard  University's  PDP-10  Computer.  That  design 
is  now  complete  and  the  language  processor  that  was  built,  CEL, 
is  now  running.  The  purpose  of  this  paper  is  to  describe  the  language 
and  its  use. 

There  are  today,  it  has  been  estimated,  over  1700  differ¬ 
ent  programming  languages  in  over  40  special  application  areas. 

Thus  he  who  proposes  another  language  must  either  be  able  to  show 
that  it  serves  a  purpose  not  already  better  served  by  one  of  its  pre¬ 
decessors  or  else  be  judged  guilty  of  having  done  no  more  than  con¬ 
tributed  to  the  flood  of  languages.  We  will  argue  that  the  language 
presented  here  is  especially  useful  for  a  significant  class  of  users  and 
variety  of  uses  by  virtue  of  being  both  conversational  and  extensible. 
We  will  argue  further  that  the  properties  of  conversationality  and  ex¬ 
tensibility  are  particularly  suited  to  being  combined  in  a  single  lan¬ 
guage.  Thus  we  feel  justified  in  unleashing  CEL  on  the  world. 
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SECTION  n 


The  Limits  of  Conventional  Languages 


A,  An  Introduction 

In  computing  we  have  theoretical  constructs  (e.  g.  the  Turing 
Machine  or  Markov  Algorithm)  capable,  if  Churches  Thesis  is  correct, 
of  computing  any  result  for  which  we  can  specify  a  sufficiently  pre¬ 
cise  procedure.  Yet  we  find  that  the  practical  problem  of  computing 
something  even  moderately  complex  is  often  a  great  strain  on  our 
talents.  It  may  be  that  a  reason  for  this  distinction  between  what  is 
computable  in  theory  and  what  is  computable  in  practice  is  the  inade¬ 
quacy  of  the  tools  we  use  to  describe  computation  to  our  machines  - 
that  is,  programming  languages. 

Programming  languages  range  from  absolute  machine  code 
and  assembly  languages  to  a  wide  variety  of  higher  level  languages. 

The  former  give  us  total  flexibility  and  computational  power  and  the 
efficiency  of  hand  tailored  models.  The  price  we  pay  for  this  power 
and  efficiency  is  that  programs  written  in  assembly  languages  to  solve 
hard  problems  are  generally  of  immense  length  and  complexity.  In 
this  respect  one  notes  that  the  production  of  the  OS/360  operating 
system  has  so  far  taken  three  man  millenia  of  effort  and  cost  on  the 
order  of  100  million  dollars.  The  current  result  is  a  program  whose 
length  is  over  5  million  lines  of  code  and  which  is  still  not  completely 
debugged[22]. 

Hence  for  a  wide  variety  of  problems  we  have  sought 
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refuge  from  this  complexity  in  the  higher  level  languages.  Let  us 
consider  then  the  scope  of  applicability  of  various  kinds  of  higher  level 
languages.  It  is  a  reasonable  approximation,  for  this  purpose,  to 
classify  higher  level  languages  as  either  special  or  general  purpose 
and  to  break  down  the  latter  class  into  monolithic  and  extensible  (or, 
to  use  Cheatham's  terms,  shell  and  core)  languages. 

B.  Special  Purpose  Languages 

Two  of  the  best  known  special  purpose  languages  are 
FORTRAN  and  ALGOL  60.  These  permit  the  production  of  programs 
that  are  fairly  readable  and  short,  especially  by  comparison  with  ma¬ 
chine  code,  for  the  things  it  is  reasonable  to  do  in  ALGOL  or  FORTRAN. 
This  includes,  however,  only  straightforward  numerical  computations. 
Attempts  at  hard  symbol  manipulation  problems  in  ALGOL  or  FORTRAN 
generally  are  so  much  less  efficient  than  machine  code,  if  perhaps 
more  readable,  as  to  be  prohibitively  expensive.  One  may  note  that 
the  reason  these  languages  are  inefficient  in  these  sorts  of  computa¬ 
tions  is  that  the  languages  do  not  provide  very  much  richness  in  their 
data  structures  or  syntax  -  what  is  there  is  built  in  and  effectively 
cast  in  concrete.  If  what  one  wants  to  do  is  readily  done  in  the  syn¬ 
tax  and  with  the  data  structures  provided,  well  and  good.  If  not,  one 
must  look  elsewhere. 

There  is  what  appears  at  first  glance  to  be  a  solution  to  this 
problem.  If  ALGOL  60,  for  example,  doesn't  provide  the  forms  appro- 
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priate  to  a  particular  problem  area,  surely  one  can  find  a  language 
that  does,  since  there  are  languages  particularly  suited  to  each  of  a 
large  variety  of  problem  categories.  This  isn't,  however,  always 
an  adequate  answer.  If  there  is  a  language  suited  to  a  problem  (and 
if  it  is  a  problem  not  like  any  previously  treated  with  computer  methods 
there  probably  won't  be)  it  may  well  be  unknown  to  the  user  who  needs 
it.  Certainly  the  learning  of  any  sizeable  subset  of  the  existing  pro¬ 
gramming  languages  is  too  great  a  burden  to  impose  on  most  com¬ 
puter  users.  Even  if  our  hypothetical  user  does  know  a  language 
suited  to  his  problem,  he  will  in  all  likelihood  discover  that  it  has  not 
been  implemented  on  the  computers  to  which  he  has  access.  Finally, 
and  most  importantly,  if  a  particular  user  requires  the  resources  of 
two  or  more  distinct  problem  oriented  languages,  he  will  find  that 
there  is  no  general  or  easy  way  to  obtain  in  a  single  language  the  de¬ 
sired  union  of  subsets  of  several  different  languages. 

C.  General  Purpose  Languages 
1.  Shell  Languages 

We  have  a  few  alternatives  remaining.  One  is  to  try,  whenever 
the  special  purpose  languages  do  not  serve,  to  use  one  of  the  general 
purpose  shell  languages,  e.  g.  ,  PL/1.  Although  these  do  provide  a 
very  rich  data  space,  they  generally  do  not  provide  very  much  varia¬ 
bility  of  syntax.  Furthermore,  they  are  built  on  the  assumption  that 
every  user  needs  all  data  structures  and  techniques.  As  a  consequence, 
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they  force  their  users  to  pay  the  overhead  associated  with  all  the 
language's  components  -  those  that  are  needed  for  a  problem  as  well 
as  those  that  are  not.  The  construction  of  such  all  inclusive  blends, 
besides  being  a  massive  programming  effort,  must,  by  its  very  nature, 
involve  the  making  of  a  number  of  decisions  at  the  time  of  language 
design.  Even  where  these  don't  create  anomalies  (e.  g.  7<6<5  has  the 
value  TRUE  in  PL/l)  many  are  bound  to  differ  from  the  decision  that 
would  have  been  made  by  some  class  of  future  users.  For  example, 
if  A  and  B  are  conformable  matrices,  PL/l  will  always  interpret 
A*B  as  the  element  by  element  product.  There  is  no  reasonable  way 
to  override  this  and  have  A*B  mean  the  normal  matrix  product. 

2,  Extensible  Languages 

If  then,  there  is  a  never  ending  source  of  problems  for  which 
existing  special  purpose  and  shell  languages  are  not  suited,  we  will 
be  forced  to  build  a  new  language  processor  for  each  of  a  number  of 
machines  every  time  such  a  problem  arises.  When  one  considers  the 
number  of  existing  programming  languages,  it  becomes  clear  that  many 
people  have  found  it  necessary  to  do  just  that.  Since  the  building  of 
a  language  processor  usually  requires  a  substantial  investment  of 
time  and  money,  an  investment  one  would  prefer  to  make  in  a  more 
direct  attack  on  the  problem  one  is  solving,  the  cost  of  this  approach 
makes  it  impractical  as  anything  more  than  a  stopgap  if  there  is  another 
option  open. 
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Therefore  we  claim  that  what  is  needed  is  a  type  of  language 
which  is  sufficiently  flexible  in  its  syntax  and  data  as  to  be  moldable 
into  the  forms  required  for  a  large  class  of  problems  at  a  cost  much 
below  that  of  producing  a  new  language  from  scratch.  We  further  claim 
that  the  core  or  extensible  language  is  of  this  type.  Before  proceeding 
to  describe  such  languages,  and  in  particular  CEL,  we  point  out  that 
the  choice  between  the  extensible  and  the  shell  language  is  often  not 
clear-cut.  The  user  of  an  extensible  language  who  must  extend  it, 
for  some  problem,  to  the  level  of  complexity  of  a  PL /I,  will  probably 
produce  a  product  that  is  a  good  deal  less  workable  than  PL/l.  More¬ 
over,  the  user  whose  problem  area  requires  the  use  of  forms  avail¬ 
able  in  some  shell  language,  may  find  that  the  shell  representation  is 
sufficiently  more  efficient  than  any  he  can  build  out  of  the  primitives 
of  an  extensible  language,  to  make  it  cheaper  to  pay  the  extra  overhead 
associated  with  the  use  of  a  shell  language.  The  extensible  language 
is  not  intended  to  best  serve  the  needs  of  users  with  problems  of  these 
sorts.  It  is  intended  for  the  user  for  whom  convenience  of  represent¬ 
ation,  directness  and  ease  of  use  and  variability  of  syntax  are  more 
precious  commodities  than  efficiency  of  execution. 
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SECTION  in 


Features  of  Extensible  Languages 


A .  Data 

The  object  of  the  extensible  language  is  the  provision  of  a 
variable  and  flexible  syntax  and  a  data  space  that  will  host  a  very  large 
variety  of  problem  types.  The  designs  of  the  extensible  languages 
now  extant  suggest  that  a  sufficiently  rich  data  space  is  obtained  by 
adding  to  the  data  types  of  the  conventional  languages  a  few  data  type 
definition  operators.  These  are,  in  general,  operators  which  act  on 
existing  data  types  to  produce  new  data  types.  Let  us  now  describe 
these  operators  and  the  definition  process. 

One  begins  with  the  set  of  atomic  types  initially  defined  in 
the  base  language.  These  are  usually  those  types  which,  though  defin¬ 
able  by  means  of  the  data  type  definition  operators,  require  special 
treatment  for  purposes  of  efficiency  and  are  likely  to  be  required  in 
a  significant  class  of  extensions  of  the  base.  Such  a  set  might  be 
[ real,  integer,  literal,  nil],  though  it  might  also  contain  multipre¬ 
cision  varieties  of  these.  Let  us  now  list  the  data  type  constructors. 

The  first  of  these  is  the  operator  that  defines  row  construct¬ 
ors.  It  takes  as  arguments  a  data  type  and  a  positive  integer  length 
and  produces  a  constructor  that  creates  rows  of  that  length  when  applied 
to  arguments  of  that  type.  For  example,  if  l”  denotes  the  row  of  n 

integers  1,  2 . n  then  I*'  =  row( integer,  n)(l . n).  Several  points 

should  be  noted  about  this  constructor.  First,  it  is  sufficient  to  pro- 
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vide  a  one  dimensional  array  constructor  since  an  array  ofhigher  di¬ 
mension  k  can  be  represented  as  a  row  of  k  (k-1) -dimensional  arrays. 
Second,  this  constructor  will  construct  only  homogeneous  rows  - 
rows  whose  elements  all  have  the  same  type.  There  are  good  reasons, 
related  to  the  efficiency  of  compiled  code,  for  including  this  constraint 
in  compiled  languages.  In  CEL  however,  as  we  shall  see,  these  are 
not  operative.  Third  we  note  that  the  row  data  type  constructor  may 
permit  the  length  to  be  missing.  In  this  case  the  data  type  produced 
will  be  a  row  of  dynamic  length. 

A  second  data  type  constructor  is  the  struct  (to  use  the 
terminology  of  BASEL).  It  creates  data  types  that  have  several  com¬ 
ponents,  in  general  of  different  types.  For  example  the  type 
struct(rp;real,  ip:real)  has  two  real  components,  called  rp  and  ip  re¬ 
spectively,  and  is  useful  to  model  complex  numbers.  In  general 
struct(S|:ti)i=i  is  a  data  type  with  n  components,  the  i  called  s{  and 
of  type  ti.  Another  instance  of  this  is  a  struct(stack;row(100,  real),  level: 
integer)  which  might  be  used  to  model  a  stack  of  reals  whose  maximum 
depth  is  100. 

A  third  data  type  constructor  creates  references,  i.  e.  , 
pointers  to  data.  We  note  that  one  useful  application  of  the  ref  is  the 
modeling  of  "call  by  reference"  in  a  language  that  does  not  explicitly 
provide  for  it  -  since  the  value  of  a  ref  is  a  pointer  to  the  datum  and 
the  value  of  this  value  is,  in  turn,  the  datum  pointed  to.  Moreover 
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it  permits  sharing  -  that  is,  the  independent  accessing  of  the  same 
datum  via  different  pointers. 

Finally,  extensible  languages  generally  provide  a  union 

n 

constructor  which  acts  on  a  set  of  types  {lii  to  produce  a  type  t 
defined  by  (x  is  of  type  t)< -->  (3  i)  (K^i<n)(x  is  of  type  tj).  For  exam¬ 
ple,  we  can  use  union  to  define  "list-of-integers**  as  follows 
list-of-integers  =  union  (pair-of-integers ,  nil ) 
pair-of-integers  =  struct  (headrinteger ,  tail:list-of-integers). 
We  note  that  there  is  usually  a  type  denoted  by  any(or  general  or  free) 
defined  by  (x  is  of  type  any)  <  -  ->  TR  UE ,  i.  e.  ,  every  datum  is  of  this 
type. 

Having  constructed  an  extended  set  of  types,  we  need  a  num¬ 
ber  of  functions  to  transact  with  them.  These  may  be  classified  as 
constructors,  predicates  and  selectors.  For  each  non-atomic  type  t 
we  need  a  function  ''construct-t"  which  given  an  appropriate  set  of 
arguments  constructs  a  datum  of  type  t.  We  need  a  predicate  on  two 
arguments  which  for  a  datum  x  and  a  type  t  tells  us  whether  x  is  of 
type  t.  Finally,  we  need  selectors  which  produce  from  a  datum  its 
component  parts. 

We  note  that  selection  is  trivial  for  rows,  and  is  accom- 

n 

plished  by  subscripting.  For  a  data  type  struct  (s*:ti),«^]  the  constructor 

n 

is  a  function  t  =  {Xxj^Xx^.  .  .  Xx^.  struct (S|:x.i)._jj  and  the  selectors  are 
the  functions  fj  such  that  fj(t(x^, .  .  .  ,Xj^))  =  xj.  It  is  clear  that  there 
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are  a  number  of  choices  to  be  made  as  to  how  constructed  data  types 
and  their  associated  functions  are  to  be  designated.  Let  us  therefore 
indicate  the  choices  made  in  three  extensible  languages  -  Jorrand's 
BASEL[4,6,8,16],  Garwick's  GPL[8,18],  and  CEL. 

In  BASEL  to  define  the  mode  complex  and  deal  with  it  one 
might  write 

(let  complex  rep  struct[real  rp,  real  ip], 
z  complex  m 

z  =  complex[l.  0,  2.  O];  rp  o£z  =  4.  0;.  ,  .  ) 

We  note  that  here  the  data  type  name  itself  is  the  name  of  the  con¬ 
structor  function  and  that  selection  is  accomplished  with  the  operator 
of.  BASEL  provides  a  union  type  operator  as  described  above  and 
a  special  predicate  to  test  the  type  of  a  variable,  e.  g.  , 

(let  u  be  union(int  or  bool) 
u  =  1;.  .  . 
u  =  TRUE;.  .  . 
when  u  is  int  then 
factorial[u]  else . ) 

BASEL  has  a  pointer  data  type  called  loc  and  provides  a  function 
alloc  which  creates  data  of  this  type,  e.  g.  , 

(let  i  be  int,  j  be  loc  int  in 
i  =  l;j  =  alloc  2; 
j-->i;i  =  plusfi,  val  i1;. .  . ) 

Here  the  operator  val  follows  the  pointer  and  the  operator 
points  the  pointer  at  i. 
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A  variable  which  is  a  row  of  k  real  numbers  in  BASEL  has 
type  row  k  of  real,  where  k  is  a  positive  integer.  If  arrays  of  dynamic 
size  are  desired,  any  may  be  substituted  for  k  in  the  mode  descriptor.. 

Similarly,  to  declare  complex  in  GPL  one  would  write 
block  complex  f  real  rp,  ip}; 

complex  z;z-->complex{l.  0,  2.  0);4.  0-->rp(z);,  .  .  ) 

Here  the  data  type's  name  is  the  name  of  the  constructor  function. 

The  is  GPL's  assignment  operator.  Selection  is  denoted  by 

functional  notation.  Although  GPL  does  not  explicitly  provide  a  union 
operator,  its  pointers,  which  have  mode  ptr  ,  can  point  to  data  of  var¬ 
iable  type.  A  predicate  much  like  that  in  BASEL  is  provided  for  type 
testing,  e.  g.  ,  one  might  write 

iff  integer  u  .  .  .  ;  i^  boolean  u; .  .  . 

One  defines  an  array  data  type  in  GPL  by  writing,  for  ex¬ 
ample,  "array  vector  of  real.  "  This  defines  the  type  vector  to  mean  a 
linear  array  of  real  numbers,  each  accessed  by  specifying  its  ordinal 
position  in  the  array.  GPL  permits  the  bounds  of  such  an  array  either 
to  be  specified  by  declaration  or  determined  dynamically. 

The  nearest  equivalents  of  these  examples  in  CEL  have  some¬ 
what  different  behavioral  properties  because  CEL  is  an  interpretive 
language.  This  means  that  the  machinery  of  the  language  processor 
is  all  present  at  the  time  of  program  execution  and  hence  that  it  is 
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possible  to  dispense  with  type  declarations.  The  type  of  a  variable 
is  simply  the  type  of  the  last  datum  assigned  to  it  or  NIL  if  no  assign¬ 
ment  to  it  has  occurred.  Another  way  to  view  this  is  to  think  of  type 
as  a  property  not  of  variables  but  of  values.  To  make  Z  the  complex 
1.  0+2.  01  one  would  write,  without  preliminaries, 

Z<--MKSTR(RP:1.  0,IP:2.  0). 

The  function  MKSTR  is  one  of  CEL's  library  functions  and  creates  a 
datum  of  type  struct.  If  one  wishes  to  create  data  of  type  complex 
more  conveniently,  one  can  define  a  function  COMPLEX,  taking  two 
arguments  and  returning  a  datum  constructed  as  above.  Then  one  could 
write,  as  in  GPL  or  BASEL, 

Z<--COMPLEX(l.  0,  2.  0). 

Having  defined  the  type  complex,  one  might  choose  to  model  quatern¬ 
ions  using  the  same  constructor,  giving  it  not  real  but  instead  complex 
arguments.  Since  types  are  dynamic,  one  could  write 

Z<--COMPLEX(COMPLEX(l.  0,2.  5),  COMPLEX(3.  1,  -4.  7)). 

Selection  from  a  struct  is  accomplished  by  writing  the  name 
of  the  component  desired  in  square  brackets  following  the  expression 
whose  value  is  the  struct.  For  example  if  Z  is  a  struct(RP:l.  0,IP:-2.  5) 
then  Z[RP]  =  1.  0  and  Z[IP]  =  -2.  5.  Selection  can  be  iterated  for 
struct 's  with  components  that  are  struct 's,  e,  g.  ,  If  a  is 
struct(al;struct(a2;struct(a3;x)))  then  a[al;a2;a3]  =  x.  Selection  can 
also  be  accomplished  by  subscripting  with  the  ordinal  position  of  the 
component  desired,  as  in  GPL.  For  example,  a(l)(l)(l)  =  x. 
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Predicates  to  test  the  type  of  a  variable  are  available  in 
several  varieties.  First  of  all  there  is  a  library  function  ILK  which 
returns  the  type  of  its  argument  as  an  integer  code  (see  Appendix  A). 
Further  discrimination  is  possible  via  the  invocation  of  library  functions 
that  return  the  number  of  components  of  a  struct  or  the  name  of  its 
i^^  component  as  a  literal.  One  may  more  conveniently  test  the  type 
of  a  datum  by  defining  the  constructor  in  such  a  way  that  it  will  insert 
the  additional  information  at  the  time  of  construction,  for  example 
Z  MKSTR  (TYPE:"COMP",RP:l.  0,IP:3.  2) 

Z2<.-  MKSTR  (TYPE:"POLAR'’,RHO:l.  0,THETA:3.  2) 

We  note  that  constructor  functions  defined  to  create  data  of  type  Z1 

or  Z2  would  still  take  two  arguments.  We  claim  that  this  method  of 

detecting  type  is  probably  optimal,  since  any  given  user  of  the  language 

will  want  to  distinguish  between  only  a  subset  of  the  data  structures  he 

is  using,  and  he  can  insert  the  minimum  amount  of  additional  information 

into  the  data  structures  that  is  needed  for  this  purpose. 

It  should  be  noted  that  the  dynamic  types  of  CEL,  as  opposed 
to  the  declared  and  fixed  types  of  languages  such  as  BASEL  or  GPL, 
are  not  always  an  advantage.  In  particular,  if  types  are  dynamic,  it 
is  necessary  to  execute  programs  interpretively  so  that  type  testing 
and  switching  are  done  correctly.  The  BASEL  or  GPL  processors, 
on  the  other  hand,  will  refuse  to  compile  a  statement  of  the  form 
'rp  of_z  =  alloc  1.  0^  if  z  is  complex.  They  can  thus  virtually  eliminate 
run  time  type  switching  (exceptions  being  the  iff  clause  of  GPL  and  the 
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when  clause  of  BASEL)  whereas  it  is  always  present  in  CEL.  The 


tradeoff  here  is  the  standard  one  between  efficiency  and  flexibility. 

The  notion  of  union  in  GPL,  BASEL  and  other  extensible 
languages  is  primarily  a  means  of  overcoming  the  restrictions  imposed 
on  the  values  of  variables  by  type  declarations.  Since  CEL  contains 
no  declarations,  the  union  op*eration  is  largely  superfluous,  except 
where  used  for  the  convenient  creation  of  predicates  for  testing  type 
class  membership  as  described  below. 

Rows  are  created  in  CEL  in  two  ways.  The  first  is  by  in¬ 
voking  the  library  function  MKROW  which  takes  as  arguments  any  num¬ 
ber  of  data  and  creates  a  row  having  these  data  as  its  elements.  The 
second  method  of  row  creation  is  via  the  function  MKNRW  (Make  Nil 
Row)  which  takes  a  single  positive  integer  as  argument  and  creates 
a  row  of  that  length  with  all  its  elements  initially  of  type  NIL.  Since 
CEL  types  are  dynamic,  CEL  need  not  make  special  provision  for 
rows  of  dynamic  size. 

One  property  of  BASEL  or  GPL's  declarations,  however, 
would  for  some  purposes  be  a  great  convenience  in  CEL.  This  ifif  that  a 
type  definition  automatically  creates  convenient  notations  for  the  con¬ 
structor  and  predicate  functions.  Indeed,  let  us  describe  a  possible 
straightforward  extension  of  CEL  that  would  add  to  CEL  a  data  defin¬ 
ition  facility  of  the  sort  offered  in  BASEL  or  GPL.  In  particular  we 
want  a  facility  which  accepts  the  equivalent  of  BASEL'S  'let  complex 
rep  struct[real  rp,  real  ip]'  and  automatically  adds  to  the  system  a 
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constructor  function  that  creates  complex  data  and  a  predicate  that 
tests  whether  an  arbitrary  datum  is  complex.  It  need  not  add  selection 
functions,  since  a  sufficient  facility  for  these  is  automatically  present, 
e.  g.  ,  if  z  is  a  struct(rp;l.  0,ip:2.  0),  then  z[rp]  and  z[ip]  (also  z(l)  and 
z(2))  are  its  components. 

Consider  the  terminal  sentences  generated  by  <ddef>  in  the 
following  grammar: 

<dde£>:;  =$<definiendum>  =  <definiens  >$ 

<definiendum>;:  =<  identifier  > 

<type>::  =< identifier >1  real  |  integer)  literal)  any)  nil 
<definiens>;:  =< structure  pattern>| <alternate  pattern>] 
<sequence  pattern>)  <reference  pattern> 

<structure  pattern>;;  =struct(< pattern  component  list>) 
<pattern  component  lis1>;:=< pattern  component>)  <pattern 
component>  ,< pattern  component  list> 

<pattern  component>:;  =< selector>r^ type> 

<selectoi>;;  =<identifier> 

<alternate  pattern>;:  =<type>)  <type>  or_  <alternate  pattern> 

< sequence  pattern>;;  =seq(<typ^) 

<  reference  pattern>::  =ref  (<type>) 

These  are  a  modified  version  of  a  subset  of  the  data  definition  com¬ 
ponent  of  Standish's  Polymorphic  Programming  Language  (PPL). 

The  semantics  associated  with  the  rules  of  the  above  are  most  easily 
explained  via  some  examples.  Consider  the  following  <ddef>'s : 
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1.  Complex-g  struct  (rp;real.  ip:real) 


2.  Complexrow  =  seq(complex) 

3.  L is tof complex  =  complex  or  pairofcomplex 

4.  Pairofcomplex  =  struct(car;listof complex.  cdr:listofcomplexl 
(1)  and  (2)  define,  respectively,  complex  variables  and  rows  of  indef¬ 
inite  length  of  complex  variables.  (3)  and  (4)  define  a  list  structure 
whose  atoms  are  complex  variables  (for  further  details,  see  Section  VI  B), 
We  desire  the  result  of  writing  these  definitions  to  be  that  the  system 
generates  several  functions  - 

(a)  three  constructor  functions  -  complex,  complexrow 
and  pairofcomplex  which  take  two,  indefinitely  many 
and  two  arguments  respectively  and  produce  structures 
of  the  appropriate  form  and 

(b)  predicates  of  the  form  element(x,  t)  (which  we  will 
write  as  xet)  whose  domain  is  {x|  x  is  a  datum} x 
{t|  t  is  a  <type>}  which  will  now  have  the  value 
TRUE  for  the  following  pairs  of  the  form  (datum,  type): 
(complex,  complex),  (complexrow,  complexrow), 

(complex,  listofcomplex) ,  (pairofcomplex,  listofcomplex), 
and  (pairofcomplex,  pairofcomplex)  as  well  as  those 
pairs  for  which  it  was  previously  true. 

We  now  give  a  precise  description  of  the  functions  which  are  added 
to  the  set  of  defined  functions  for  each<ddef>.  In  what  follows  s  and 
Si  will  denote  <selectoic» 's  and  t  and  tj  will  denote  <type>'s.  I(t) 
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is  a  unique  constant  associated  with  the  identifier  t. 


For  each<dde£>  with  <def ini endum>  the  identifier  t,  create 
a  struct  named  t  and  equal  to  £truct(predicate;a,  constructor :b)  with 
a  and  b  defined  as  follows: 

If  the  <definiens>  is  a  < structure  pattern>  of  the  form 
struct(s»;tj)._j  set  t[predicate]  =  {Xx.  x[type]  =  i(t)}  and  t[constructor]  = 

{Xxj.  .  .  Xxjj.  MKSTR((Si:tj)j_j  ,type:i(t)  } 

If  the  <definiens>  is  an<alternate  pattern>  of  the  form 
ti  or  ,  .  .  or  tjj  set  t[predicate]  =  {\x.  (xetj)  or  .  . .  or  (xet^)}  and  leave 
t[constructor]  undefined. 

If  the  <definiens>  is  a<sequence  pattern>  of  the  form 
seq(t')set  t[constructor]  =  {Xxj  .  .  .  Xx^^  MKROW(xj,  .  .  .  ,x^)j  and  t[predicate] 
{Xx.  x(l)et'  AILK(x)  =  seq}.  (In  this  and  the  next  definition,  we  use 
'ref  and  'seq'  as  variables  whose  value  is  the  internal  code  for  the 
types  ref  and  seq  ,  respectively).  Here  n  is  indeterminate. 

Finally,  if  the  <definiens>  is  a  < reference  pattern>  of  the 
form  ref(t')  set  t[predicate]  =  {Xx.  (VLPTR(x)et')A(ILK(x)  =  ref)}  and 
t[constructor]  =  {Xx.  MKREF(x)]. 

Define  the  construct  and  element  functions  by: 

Construct((x|)^”j  ,  t)  =  if  atomic(t)  then  undefined  else  t[con- 
structor](x£)i=j  ;Xet  =  if  atomic(t)  then  (ILK(x)  =  i(t))  else  t[predicate](x); 
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B .  Syntax 

Much  of  the  effectiveness  that  is  the  goal  of  the  extensible 
language  is  lost  if,  although  data  types  are  flexible,  syntax  is  not. 

A  programmer  who  has  defined  a  set  of  unusual  data  types  for  a  par¬ 
ticular  application  will  probably  want  to  program  in  a  notation  similarly 
selected  for  that  application.  If,  for  example,  he  has  defined  a  data 
space  that  contains  list  structured  objects,  he  may  wish  to  decree  that 
*x+y*  is  to  have  the  value  obtained  by  concatenating  x  and  y  whenever 
either  is  a  list,  and  the  previously  defined  value  in  all  other  cases. 

If  his  application  is  such  that  he  must  frequently  write  the  equivalent 
of  the  special  case  '*for  i  =  1  step  1  until  n  do  .  .  .  “  of  the  ALGOL  60 
for  statement,  he  may  wish  to  specify  that  that  is  the  meaning  of 
**for  i  -->n  do  .  .  .  *'.  In  short,  he  wishes  to  define  a  syntax  which 
emphasizes  what  is  variable  in  his  application,  minimizes  what  is 
constant  and  mirrors  the  laws  of  combination  and  growth  of  the  ob¬ 
jects  he  is  manipulating. 

BASEL  provides  no  such  facility,  but  it  is  intended  to  be 
part  of  a  larger  "extensible  language  facility"  which  would  presumably 
permit  some  kind  of  syntax  variability[6].  GPL  contains  three  methods 
for  achieving  a  flexible  syntax.  First,  it  permits  the  definition  of  new 
infix  operators  with  associated  priorities.  Second,  it  allows  a  much 
more  general  form  of  procedure  call  than  is  conventional,  e.  g.  ,  per¬ 
mitting  a  user  to  define  "ifmid  a  of  b,  c  then  d  else  e"  as  the  calling 
sequence  for  a  procedure  ifmid  on  five  arguments.  Finally,  GPL 


-18- 


contains  a  macro  expansion  facility  whereby  after  the  declaration 


procedure  dist(a,  b); 

iff  2  space  a,  b  take  macro  sqrt((x(a)  -x(b))t  2+(y(a)  -y(b))t  2); 
an  occurrence  of  "dist(s,t)"  will  be  expanded  to  produce  the  in  line 
code  ’'sqrt((x(s)  -x(t))t2+{y(s)  -y(t))t2)”. 

A  somewhat  more  general  and  powerful  facility  for  adding 
syntax  variability  employs  the  mechanism  of  the  Brooker  and  Morris 
Compiler-Compiler.  Here  one  specifies  an  augmented  BNF  grammar 
for  the  language  in  which  one  wants  to  program.  The  augments  can, 
for  example,  be  transduction  elements  which  translate  a  user's  ex¬ 
tension  of  the  base  syntax  into  the  system's  base  language[3,  30]. 

The  component  of  CEL  which  provides  syntax  variability  is 
at  present  ad  hoc,  and  we  intend  eventually  to  provide  a  facility  of  the 
Brooker  and  Morris  sort  in  CEL.  In  the  current  definition,  a  user 
provides  a  function,  written  in  CEL,  which  when  invoked  will  trans¬ 
late  a  statement  in  the  language  in  which  the  user  wishes  to  program 
to  the  equivalent  CEL  base  statement.  That  it  is  possible  to  write 
functions  in  CEL  which  act  as  syntax  transducers  is  demonstrated 
by  some  of  the  examples  of  CEL  programs  given  below.  However  it 
is  equally  clear  that  one  does  not,  in  general,  want  to  require  a  CEL 
user  to  program  his  own  transduction  algorithm,  and  hence  we  will 
replace  this  mechanism  by  one  of  greater  sophistication  in  a  future 
revised  definition  of  CEL. 
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C.  Control 

Programming  languages  have  several  aspects  whose  system¬ 
atic  variation  we  may  profitably  study.  Thus  far  we  have  discussed 
the  data  and  syntax  of  extensible  languages.  One  might  also  want  to 
vary  the  control  structure  of  a  language,  e.  g.  to  obtain  co-routines, 
clock  driven  simulations,  multiple  parallel  returns  by  subroutines, 
parallel  processing,  continuously  evaluating  expressions,  and  so  on. 
Thus  one  would  expect  an  ideal  extensible  language  to  provide  mechan¬ 
isms  for  varying  control  that  were  sufficient  to  add  such  features. 
Unfortunately,  determining  what  constitutes  an  optimal  (or  even  a  good) 
set  of  primitives  from  which  common  control  structures  can  be  built, 
is  at  present  an  unsolved  problem.  We  know  of  no  existing  implementa¬ 
tion  of  an  extensible  language  which  provides  such  features  (with  the 
possible  exception  of  ALGOL  68 's  parallel  execution  expression  and 
PL/l's  ON  statement)  although  Standish's  design  of  PPL  does  make  a 
number  of  such  provisions  which  depart  from  orthodox  control  struc- 
tures[29,  3l].  Introducing  such  facilities  into  CEL  would  probably 
require  a  drastic  departure  from  the  current  implementation's  scheme 
of  driving  program  execution  from  a  pair  of  push  down  stacks.  Hence 
we  leave  the  problem  of  designing  and  implementing  mechanisms  for 
including  variability  of  control  structures  in  higher  level  languages 
to  future  researchers. 
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SECTION  IV 


Conversation  and  Interpretation 

IV.  Conversation  and  Interpretation 

Let  us  now  digress  temporarily  from  the  subject  of  extensib¬ 
ility  to  discuss  the  styles  of  debugging  typical  of  each  of  two  broad 
classes  of  languages,  the  non-interactive  and  interactive.  The  first 
of  these  consists  of  languages  which  are  usually  compiled  and  executed 
in  a  'batch'  environment.  Most  implementations  of  PL/1,  ALGOL  60, 
FORTRAN  and  COBOL  are  in  this  category.  On  the  other  hand,  there 
are  interactive  languages  which  are  usually  executed  interpretively 
in  a  form  close  to  that  in  which  the  programmer  wrote.  These  languages 
permit  the  user  to  interact  with  a  running  program  and  to  compose, 
modify  and  debug  programs  at  a  rapid  pace.  We  generally  find  these 
in  a  time -shared  and  conversational  environment  -  such  languages  as 
APL,  JOSS,  CAL,  LISP,  and  so  on. 

Detecting  errors  in  a  non-interactive  environment  is  usually 
a  time  consuming  and  tedious  task.  Typically  one  submits  a  program, 
for  example  as  a  deck  of  cards,  and  several  hours  later  gets  it  back 
along  with  the  results  of  the  run.  Usually  these  results  are  some 
mixture  of  wrong  results  and  error  messages.  At  this  point,  since 
one  cannot  interactively  control  and  modify  the  program's  execution, 
one  can  track  down  the  source  of  errors  only  by 

(a)  desk  checking  -  carrying  out  parts  of  the  computation 
by  hand,  as  the  program  directs,  with  sample  inputs  or 

(b)  requesting  periodic  printouts  of  partial  results  during 
the  program's  next  run. 

One  generally  employs  some  combination  of  these  and  gets,  at  the 
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end  of  the  second  and  successive  runs,  massive  amounts  of  material, 
most  of  it  irrelevant  to  the  problem  of  error  detection,  which  must 
nevertheless  be  scanned  through  in  an  attempt  to  find  the  significant 
parts.  If  it  is  the  case  that  one  can  learn  nothing  at  all  from  the  re¬ 
sults  produced  after  the  first  couple  of  errors  occurred,  then  one 
is  faced  with  the  necessity  of  iterating  this  procedure  several  times 
in  order  to  detect  bugs  in  a  non-trivial  program. 

Debugging  in  languages  of  the  second  kind  is  a  much  less 
unpleasant  task.  Because  the  environment  is  interactive,  one  can 
dispense  with  core  dumps  and  instead  selectively  investigate  relevant 
evidence  of  errors.  Good  interactive  languages  permit  one  to  study 
partial  results  and  to  phrase  questions  at  the  level  of  the  source  pro¬ 
gram.  In  addition  one  can  desk  check  far  more  easily  than  in  a  batch 
system,  because  one  can  use  the  computer  to  do  the  mechanical  parts 
(e.  g.  hand  computation)  of  desk  checking. 

In  most  conversational  language  systems  there  are  a  num¬ 
ber  of  features  that  further  ease  the  debugging  process.  APL,  for 
example,  a  prime  example  of  a  well-constructed  conversational  lan¬ 
guage  system,  allows  the  programmer  to  set  break  points  in  the  pro¬ 
gram  which,  when  encountered  during  execution,  will  suspend  exe¬ 
cution  and  return  control  to  the  user's  teletype.  He  can  then  examine 
and  modify  the  values  of  variables  before  continuing  the  computation 
at  the  break  or  any  other  point.  APL  further  permits  the  user  to  trace 


-22- 


the  execution  of  a  subset  of  program  statements,  i.  e.,  to  specify  that 
every  time  one  of  these  statements  has  been  executed,  the  number  of 
the  statement  and  its  result  are  to  be  output  on  the  user*s  teletype.. 
Once  an  error  has  been  located  by  these  means,  a  user  may  edit  single 
statements  or  larger  parts  of  the  program,  and  immediately  inves¬ 
tigate  the  effect  of  the  changes  made[l,  15],  Finally,  we  note  that  in 
a  conversational  system  one  can  take  advantage  of  strange  occurrences 
(e,  g.  ,  a  computation  taking  longer  than  it  should  or  an  output  that 
differs  from  expectations)  to  look  at  the  effect  of  an  error  near  its 
source.  In  batch  systems,  by  comparison,  one  frequently  detects 
the  presence  of  an  error  via  some  subtle  change  at  a  remote  place 
in  the  program  or  its  output. 

Lest  we  be  accused  of  unfairly  stating  the  relative  merits 
of  interactive  and  non-interactive  systems,  we  hasten  to  point  out  that 
experimental  comparisons  of  productivity  in  these  two  media  are  not 
conclusive.  It  is  difficult  to  obtain  good  comparisons  between  pro¬ 
grammers  working  in  different  languages  and  at  the  same  time  it  is 
unfair  to  draw  conclusions  from  the  performance  of  a  batch  language 
in  a  time-shared  system  or  vice-versa.  Thus  we  can  only  state  our 
own  distinct  preference  for  conversational  systems  and  point  to  the 
similar  statements  and  results  of  others [14,  24,  27 ]. 

It  is  certainly  the  case  that  interpreted  programs  do  not 
run  as  rapidly  as  compiled  versions  of  the  same  programs.  However, 
in  many  applications  such  factors  as  the  programmer’s  ability  to 
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absorb  results  acts  as  a  more  restrictive  constraint  than  running  time. 
Moreover,  one  can  often  achieve  the  best  results  of  both  compilation 
and  interpretation  by  including,  in  an  interpreted  language,  a  compile 
operator  (e.  g.  the  one  in  LISP)  which  one  applies  to  a  function  after 
one  is  through  debugging  it.  It  is  converted  into  machine  code  and 
thereafter  runs  at  the  rate  of  a  compiled  program.  Finally  there  is 
evidence  (qv.  [14])  that  total  costs  of  man  hours  and  machine  time 
are  lower  in  time-shared  systems. 

We  claim  that  the  dynamic  style  of  programming  in  a  con¬ 
versational  system  meshes  very  nicely  with  the  flexible  nature  of  ex¬ 
tensible  languages.  The  resulting  freedom  is  a  major  step  toward 
making  the  process  of  programming  as  natural  as  possible  for  the  pro¬ 
grammer.  This  is  consistent  with  the  philosophical  objective,  in 
extensible  languages,  of  letting  a  programmer  express  his  thoughts 
about  a  problem  with  a  minimum  of  artifice  or  translation. 

The  pressure  of  time  has  prevented  the  inclusion  in  CEL*s 
current  implementation  of  a  full-fledged  conversational  debugging 
facility.  One  can  do  automated  desk  checking  via  an  immediate  exe¬ 
cution  feature,  but  this  would  not  be  adequate  in  the  final  form  of  the 
language.  We  hope  to  add  a  break  point  debugging  and  selective  trace 
facility  such  as  that  of  APL. 

The  current  implementation  does  not  contain,  again  because 
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of  the  pressures  of  time,  a  text  editing  component.  Until  such  a  com¬ 
ponent  can  be  implemented,  an  ad  hoc  provision  has  been  made,  where¬ 
by  CEL  programs  can  be  created  and  edited  using  the  PDP-lO's  TECO 
(Text  Editor  and  Corrector)  Program.  This  measure  has  sufficed 
for  the  creation  of  the  CEL  programs  given  below. 
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SECTION  V 


Description  of  CEL 

Let  us  now  describe  CEL  in  some  detail.  The  fragments 
of  CEL  programs  given  above  are  written  in  the  language  defined  by 
the  standard  front  end  syntaux  of  the  current  implementation.  However, 
for  the  purposes  of  this  section,  we  revert  to  thinking  in  terms  of 
CEL's  base  language.  This  is  defined  by  the  following  grammar 
with  root  symbol  <prograir>: 

1  <program>::  =<;message> 

2-3  <message> ::  =<function  definitiori>|<statement> 

4  <function  definitior£>::  =$<function  headeix function  body>$ 

5  <function  headei>:;=<;identifier>(<identifier  list>)< identifier 

list>;<identifier  list>; 

6-7  <identifier  list>::=  emptyl<identifier>{  ,<identifieK>}* 

8  <  function  body>::={<statement>}  ^ 

9  <statemenl>  ::={< express ior>  3  ^ 

10-14  <expressioiI> =<identifier> I  <constant> I  ({<expressior>3 

<expressior>  :<identifiei> |< express ior£>  ]<identifiei> 

In  this  grammar,  ::  =,  |  ,{,},  +  and  *  are  metasymbols.  { A}  *  means 
zero  or  more  A's.  [a]'*'  means  one  or  more  A's.  <identifier>  and 

<constant>  are  lexical  tokens  whose  composition  need  not  further  con¬ 
cern  us  here. 

A  CEL  program  is  a  sequence  of  either  function  definitions 
or  direct  commands.  The  former  result  in  the  saving  of  the  defined 
function  for  later  execution,  whereas  the  latter  usually  invoke  one  or 
more  previously  defined  functions.  We  see  from  (9)  that  a  statement 
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is  a  sequence  of  expressions  -  the  associated  meaning  is  that  the  ex¬ 
ecution  of  a  statement  consists  of  the  successive  evaluation  of  its 
constituent  expressions,  read  from  left  to  right.  The  value  of  an  ex¬ 
pression  e  is  recursively  defined  as  follows  (the  value  assigned  to 
<identifiei>  is  later  qualified): 

Val(e)  =  if  e  is  a  constant  then  e  else 

if  e  is  an  identifier  then  if  an  assignment  operator 
has  been  called  with  the  identifier  as  the  left 
operand,  then  the  value  of  the  right  operand  at 
the  last  such  call  within  the  scope  of  the  identifier 
and  NIL  otherwise  else 
if  e  is  of  the  form  e']i  then 

if  e'  is  a  struct  with  a  component  named  i  then  val 

applied  to  the  i  component  of  e'  and  otherwise  error 
else 

if  e  is  of  the  form  e':i  then  val(e')  else 
if  e  is  of  the  form  (e^  62  .  .  .  e')  then 

if  e'  is  a  row  then 

if  n  =  1  and  val(ei)  is  a  positive  integer  m 

tH 

<  length(e*)  then  val  applied  to  the  m  component 
of  e*  and  otherwise  error  else 
if  e*  is  a  function  then  (see  below)  else 
error; 
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We  must  now  define  the  value  of  the  expression  e  =  (ej  ...  e^  e') 
where  e'  is  a  function.  If  n  is  not  the  number  of  arguments  that  e' 
requires,  there  is  an  error  condition.  If  e'  is  a  library  function,  the 
value  and/or  side  effects  due  to  evaluating  it  with  arguments  e^,  ,  ,  .  ,  ej^ 

are  specified  in  Appendix  A.  Otherwise  e'  is  a  programmer  defined 
function.  E  is  then  evaluated  by  calling  e',  supplying  it  with  val(ei), 

.  .  .  ,  val(ej^)  as  arguments  and  using  the  result{s)  returned  by  e'  at  its 
exit  as  val{e). 

Finally  we  define  the  process  of  calling  a  programmer  defined 
function  f  with  arguments  e^, .  .  .  ,  ej^.  Suppose  the  header  of  f  is 
"f(x^,  .  .  .  ,Xg)rp  .  .  .  ,  ...  1 that  it  contains  k  statements, 

numbered  1, .  .  .  ,  k.  Then  to  call  f  we 

(1)  Set  a  program  counter  c  to  one. 

(2)  Execute  the  c'th  statement  of  f  , 

(3)  Set  c  to  c+1.  If  ok  then  exit  returning  r^^ . r^ 

as  results.  Otherwise,  proceed  from  (2). 

(A  transfer  statement  achieves  its  effect  by  changing 
the  value  of  c). 

An  identifier  i  is  evaluated  within  f  as  follows  -  if  i  is  not  one 
of  the  locals  of  f  (i.  e.  one  of  the  xj's,  r^'s  or  l^'s)  then  its  value  is 
the  same  as  if  i  had  been  encountered  outside  f.  If  i  is  a  local  of  f, 
its  value  is  that  last  assigned  to  i  since  f  was  last  entered.  If  no  such 
assignment  has  been  made  and  i  is  not  one  of  the  x^'s,  then  val(i)  =  NIL. 

If  i  is  Xj,  then  val(i)  =  val(ej).  An  assignment  within  f  to  a  local  of 
f  has  no  effect  on  the  value  of  another  identifier  of  the  same  name 
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existing  outside  f.  Here  "outside  f"  means  either  inside  some  other 
function,  inside  any  other  call  of  f  (if  f  is  recursive)  or  outside  all 
functions. 


This  base  language  has  been  chosen  for  CEL  for  several 
reasons.  It  is  relatively  simple  yet  powerful  enough  to  express  all 
the  constructs  we  wish  to  include  in  CEL.  Statements  in  it  can  be 
executed  efficiently  since  it  is  SLR(l)  (i.  e.  ,  at  any  stage  in  a  parse, 
the  next  applicable  reduction  is  unambiguously  determined  by  inspec¬ 
tion  of  at  most  one  symbol  to  the  right  of  the  current  symbol)  and 
indeed,  the  current  implementation  does  a  small  amount  of  prepro¬ 
cessing  to  make  it  SLR(O).  There  are  no  reserved  words,  which  makes 
learning  the  language  easier  than  it  would  otherwise  be.  Finally, 
we  can  translate  from  a  number  of  front  end  syntaxes  to  this  base  with¬ 
out  much  difficulty.  On  the  other  hand,  programs  written  in  the  base 
are  relatively  unreadable.  Because  we  always  intend  to  program  in 
some  front  end  syntax,  this  is  not  a  problem. 

CEL's  standard  front  end  syntax  in  the  current  implementation 
is  defined  in  terms  of  the  base  syntax  by  the  following  transduction 
grammar  G; 
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< statement>::  =< identifiei>r<expression>  @  ,p< express iorv>r< identifier> 

<  statementi>::=<expression> 

< expression>::  =<term>a< expression>  0  ^(<term>< express ion>f(a)) 
<expression>::  =a< express ion>  @rp(<expression>f(a)) 

<  expressiorO::  =<term> 

<term>::  =<constant>|<  identifier> 

<term> ::  =  (<  statement>)  @  statement> 

<terrn>::  =<terrn>()  (j^(<term>) 

<terrn>::  =<ternn>({  statement>  3  0  ,p  ([<  statement>]  ^<terrr^) 

<term>::  =<term>[<identifier>  {  identifier>]  *]  @  ^<term>]<identifier> 

[  ]<identifier>}* 

There  is  a  version  of  each  rule  containing  ’’a”  for  each  infix  operator 
that  is  to  be  used.  For  each  such  operator,  f(a)  is  the  name  of  a  CEL 
function  that  computes  its  value  for  the  correct  number  of  arguments. 

The  base  language  translation  of  a  statement  written  in  this 
syntax  may  be  determined  by  following  this  recipe  - 

(1)  Obtain  a  parse  tree  in  G  for  the  statement. 

This  is  a  particularly  easy  process  since  G 
is  an  operator  precedence  grammar  with  f 
and  g  functions  (qv.  [ll]  and  Appendix  B). 

(2)  Rearrange  the  sons  of  each  nonterminal  node  x 
(possibly  deleting  some  and  inserting  others) 
according  to  the  transduction  element  for  the 
rule  of  g  that  corresponds  to  the  node  and  its 
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sons. 


(3)  Read  off  the  terminal  nodes  of  the  modified  tree  in 

left  to  right  order,  obtaining  the  translated  statement. 
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SECTION  VI 


Programming  in  CEL 
A.  An  Introduction 

We  now  present  several  extensions  of  CEL.  Each  consists 
of  a  number  of  functions  which  manipulate  the  data  types  of  the  exten¬ 
sion.  In  order  to  conveniently  explain  how  they  work,  we  will  insert 
descriptive  text  between  fragments  of  the  actual  CEL  text,  though  of 
course  this  description  would  be  omitted  during  a  computer  session 
using  CEL.* 


*The  program  text  was  produced  by  a  device  which  uses  ”  -* 
for  and  ”  x  "  for 
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List  Processing 


The  major  data  types  of  this  extension  are  defined  as  follows; 


Atom  =  integer  or  real  or  literal  or  nil 
Pair  =  struct(car;listel,  cdr;listel) 


Listel  =  atom  o£  pair 

The  data  type  pair  corresponds  to  the  dotted  pair  of  LISP.  We  first 
define  several  of  the  elementary  functions  of  LISP  - 

$cons(a,b)r;? 

[1]  R<— MKSTR(CAR:A,CDRtB) 

$ 


$CAR(X)R?5 

[1]  AT0M(x)->4 

[2]  R<— X[CAR] 

$ 


$CDR(X)R55 

[1]  AT0M(X)->3 

[2]  R<— X[CDR] 

$ 


$AT0M(X)R5? 

[1]  R<— ILK(X)t4 

$ 


Cons  is  a  constructor  function  that  takes  a  pair  of  arguments, 
presumably  of  type  listel,  and  makes  a  pair  out  of  them.  Car  and  cdr 
are  generalized  selectors  -  they  return  the  appropriate  component  if 
it  exists,  but  NIL  if  it  doesn't  (i,  e.  if  the  argument  is  an  atom).  They 


accomplish  this  by,  for  atomic  arguments,  exiting  from  the  procedure 
without  making  an  assignment  to  the  result  R,  and  hence  return  NIL 
according  to  the  rules  given  in  Section  V.  Atom  is  a  predicate 
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which  distinguishes  atoms  from  non-atoms  using  the  fact  that  in 
this  extension  the  only  non-atoms  are  structs,  and  that  any  struct 
X  satisfies  ILK(x)  =  4.  We  next  define  a  function  list  which  creates 
structures  corresponding  to  the  list  of  LISP,  i,  e.  ,  data  x  satisfying 


(1)  xelistel  and 


(2)  if  atom(cdr(x))  then  cdr(x)  =  NIL. 


R<_-C0NS{X,NIL) 

■*20 

J<— LNGTH(X) 

R<— C0NS(X(J),R) 

(j=l)^20 

J<— J-  1 

-^5 


$ 


Lists  are  a  proper  subset  of  pairs,  but  are  often  easier  to  deal  with 
in  that  we  can  view  car  as  returning  the  first  element  of  the  list  and 
cdr  as  returning  the  list  obtained  by  deleting  the  first  element  of  the 
original  list.  Since  we  want  the  constructor  list  to  be  variadic,  it  is 
defined  so  that  it  will  accept  either  a  single  argument  or  a  row  of 
arguments,  i.  e.  ,  list(x)  =  if  atomic(x)  then  cons(x,  NIL)  else  if  ILK(x) 
=  row  then  cons(Xj^,  cons(,  ,  .  ,  cons(x^,  NIL).  .  .  )  where  n  i  s  the  length 
of  X. 


Finally  we  can  define  a  number  of  functions  on  lists  -  these  are 
standard  functions  in  LISP,  implemented  by  means  of  great  reliance  on 


the  idea  of  recursion.  Append  creates  a  list  of  all  the  elements  of 
its  arguments  lists.  Reverse  creates  a  list  in  which  the  elements 
of  the  original  list  appear  in  the  reverse  of  their  original  order. 

Showd  and  showp  make  recursive  calls  on  each  other  in  order  to 
print  a  list  showing  the  list  structure  with  parentheses.  Seek  takes 
as  arguments  an  atom  and  a  list  of  pairs,  and  returns  the  list  whose 
elements  are  the  right  halves  of  all  pairs  whose  left  half  is  the  atom. 
Replace  changes  all  occurrences  of  an  atom  in  a  list  to  another  atom. 
Same  determines  whether  two  list  structures  are  the  same  and  member 
determines  whether  one  list  is  a  sublist  of  another.  These  last  two 
are  used  by  union  to  construct  a  list  whose  elements  are  those  in  the 
union  of  the  sets  of  elements  of  the  two  argument  lists.  Finally,  map 
applies  a  function  to  successive  cdrs  of  a  list  and  returns  the  final  cdr 
(NIL  for  a  list)  as  result. 


[IJ 

[2j 

[3J 

[4] 

L5J 

[6] 


$REPLACE(A,B,L)R55 
R<— B 
(L=A)->7 
ATOM(L)->6 

R<— cons(replace(a,b,l[carJ),replace(a,b,l[cdrJ)  ) 

^7 

R<— L 

$ 


[5] 


$SAME(S,T)R;S 

ATOM(S)->5 

atom(t)->5 

R<— SAME (CAR(S) ,CAR(T) )xSAME(CDR(S) ,CDR(T) ) 

r<_.S=T 

$ 
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[1. 

[2] 

[3] 

[4 

[5] 

[6] 

[7‘ 


$SH0WD(L)55 

a'idm(l)h-7 

type(''(") 

SHOWD(L[CARj} 

showp(l[cdr]) 

typeC')") 

->8 

TYPE(L) 

$ 


[1] 

[2] 

[3] 

[4] 

[5J 

[6J 


$SH0WP(L)55 

(L=NILj->7 

atom(l)-^*6 

SH0WD(CAR(L) ) 

showp(cdr(l)) 

•*1 

TYPE(L) 

$ 


$SHOW(L)55 

[1]  SHOWDCL) 

[2]  typeC^ 

") 

$ 


[1] 

[2] 

[4] 

[5] 


[1] 

[2] 

13] 


[1] 

[2] 

[3] 


$seek(l,a)r;5 

(ILK(L)=oK6 
(A:(=CAR(CAR(L)))->4 
R<— CONS(CDR(CAR(L)),R) 
L<— CDR(L) 

->1 


$ 


$REVERSE(X)RJ5 

(ilk(x)=o)->3 

R<—APPEND(REVERSE(CDR(X)), CONS (CAR(X), NIL) ) 

$ 

$LENGTH(X)RJ5 

atom(x)->4 

R<— 1+LEN  GTH  ( CDR  ( X  )  ) 

->5 

R<~0 

$ 

$APPEND(X,Y)R55 
R<— Y 

(ILK(X)=0)->4 

R<— CON S  ( C AR  ( X  )  ,  APPEND  ( CDR(  X  )  ,  Y  )  ) 

$ 
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1' 

2' 

3] 

4] 


$MEMBER(S,T)R55 

AT0M(T)->4 

R<-._SAME {  S  , T) +S  AME  ( S  , T[  C AR  ] ) +MEMBER ( S  ,  T [  CDR ]  ) 
-^5 

R<— S=T 

$ 


1‘ 

2' 

3] 

4] 
53 
6] 


$UNI0N(L1,L2)R5S5 

(L2=NIL)->6 

MEMBER  ( L  2  [  C  AR  ] ,  LI ) ->4 
S<— C0NS(L2[CAR],S) 
L2<— CDR[L2] 

->•1 

R<— -APPEND (LI, S) 

$ 


$MAP(F,L)R55 
11]  F(L) 

[2]  atom(l)->5 

[3]  L<— CDR(L) 

[4]  ->1 

[5]  R<— L 

$ 


Some  instances  of  output  obtained  during  runs  with  this  extension 
are  as  follows: 

P<— -LI ST  ( MKRDW  ( "  A "  ,  1 , "  B"  ,  2 ) ) 

SHOW{P) 

(A1B2) 

PP  <~LI  ST  ( MKROW  ( P  ,  P  ,  P  )  ) 

SHOW(PP) 

((A1B2)(A1B2)(A1B2)) 

PP  [  CDR 5  CAR  ]<— LIS T( MKROW  (4,5,5)) 

SHOW(PP) 

((a1B2)(455)(A1B2)) 

Q<_- append (PP,PP) 

show(q) 

((a1B2)(455)(A1B2)(a1B2)(455)(a1B2)) 

R<— LIST(MKROW  ( 1 , 2  ,LIST(MKR0W  ( "  A"  ,  "  B"  )  )  ,  3 ) ) 

SHOW(R) 

(12(AB)3)  ,  , 

SHOW ( REVERSE (R)) 

(3(AB)21) 

MAP ( SHOW,  R) 

;12(AB)3) 

.2(AB)3)' 

(ab)3) 

3) 
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S<— LIST(MKR0W(C0NS("A'',i),C0NS("B",2),C0NS("C",3))) 
SHOW(S) 

((A1)(B2)(C3)) 

SHOW ( SEEK (S," a" )) 

S<— APPEND  (S,S) 

SHOW(S) 


R<— LIST(MKH0W("A"  ,"B"  )) 

s<— list{mkrow(''a''  ,R,"C^' )) 

T<— LIST(MKR0W(R,S,"A"  ,R)) 


R<— LIST(MKHOW("A"  ,"B"  ) 

s<— list(mkrow(''a''  ,R,"C 


SHOW(R) 

(AB) 

SHOW(S) 

(A(AB)C) 

SHOW(T) 

((ab)(a(ab)c 


MEMBl 

MEMBER(T,S) 
MEMBER (R,T) 


1 


0 


2 
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C  Polynomials 


[1 
[2] 
[3J 
L4: 

[5] 

[6] 

ll 

[9 
[10 
[11] 
[12 
[13 
[14 

[15] 

[16] 

[18 

[19 


Having  defined  a  definition  set  for  lists,  we  can  use  it  to 

n 

model  polynomials,  A  polynomial  a.x  is  representable  as  a 
vector  this  representation  is  inefficient  if  many  of  the 

a.'s  are  zero.  In  that  case  we  prefer  to  represent  a  polynomial 
as  a  list  of  terms,  where 


Term  =  struct(deg:integer  ,  coefrinteger  ). 

The  zero  polynomial  is  the  NIL  list.  The  following  functions  then 
suffice  to  construct,  output,  add  and  multiply  polynomials.  Examples 


of  the  output  they  produce  are  given. 


$ADDP0LY(X,Y)RJD1,D2,S5 

(xf^NIL)->4 

R<~Y 

->20 

(Yf=NIL)->7 
R< — X 
-»-20 

Dl<— CAR(X}[DEG] 

D2<— CAR(y)[DEG] 

(D1=}=D2)->-16 

S<— CAR(X)  [COEF  ]+CAR(Y)  [COEF] 

(Sf0)^l4 

R<— ADDP0LY(CDR(X)  ,CDR(Y) ) 

->20 

R<— CONS ( MKSTR ( DEG: D1 , COEF  t  S ) , ADDPOLY ( CDR( X ) , CDR ( Y ) ) ) 

^20 

(Dl-D2)->19 

R<— CONS  (CAR(Y) ,  ADD P0LY(X,CDR(Y)  ) ) 

->20 

R<— CONS  (CAR(X) ,  ADDPOLY (CDR(X)  ,Y)  ) 

$ 
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1 

2 

3] 

4' 

5] 

6 

7 

8 

9] 


$SHOWPOLY(X)sLs 
(X=NIL)^17 
L<— CAR(X) 


( ( L  [  COEP  ]=1 )  XL  [  DEG  ]  ={=0  )->5 
TYPE(L[C0EF]) 

(L[ DEG] =0)^10 

typeC'x"  ) 

(L[DEG]=1)->'10 
TYPE("t" ) 

, ,  TYPEfLfDEG]) 

10]  (cdr(x)=nil)->17 

11]  X<— CDR(X) 

12]  CAR(X)[C0EF}»14 

13]  ->2 

14]  TYPE(”+") 

15]  ^2  , 

16]  typeC'o”) 

17]  TYTB(" 


$ 


:^P0LY(R)P5J5 

1]  J<— lngth(r) 

2]  P<— CONS (MKSTR( DEG: R(J),C0EF:R(J-  l)),P) 

3]  J<— J-  2 

4]  J-*2 


$MULPOLY(Pl,P2)Rt5 

[1]  ((P1=NIL)+P2=NIL)->3 

[2]  R<— ADDP0LY(DIST(CAR(P1)  ,P2)  ,MULP0LY(CDR(P1) ,P2)  ) 

$ 


1 

2 

3 

4 


$DIST(T,P)RsL1,L25 

(p=nil)->5 

Ll<-— T[  DEG  ]+P  [C  AR5DEG  ] 

L2< — T[ COEF ]xP[ CAR5COEF ] 
R<— CONS  (MKSTR(DEG:L1,C0EF: 

$ 


L2) ,DIST(T,P[CDR])) 
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5+xe+^ix9 

( (z'x)xn[o<iaciv)x.iOciMOHS 

s+siXT-Sixe 
(Z)XIOJMOHS 
((0'5'S'T-'5'£)MaDIW)X'T0(I— >Z 

S4.X6+£iX9+i7J'X 
( ( X  '  X )  A1(H  inw )  XlOdMOHS 

xe+six 

(A)A10<IM0HS 
(  (T'C'S'T)M0HXW)X10<I— >A 


D  Formulas 


In  the  next  extension  we  will  manipulate  formulas,  i.  e.  ,  data 
defined  by  the  following  definitions: 

Form  =  struct(lp: formula,  op: literal,  rp: formula) 

Formula  =  form  or^  atom 
Atom  =  literal  or  real . 

First  we  define  several  functions  which  perform  arithmetic  operations 
on  formulas  and  do  some  simplification  (using  the  identities  l*x  =  x***!  =  x, 
0+x  =  x+0  =  X  and  0*x  =  x*0  =  0).  The  functions  named  SADD,  SMUL, 
SSUB  and  SDIV  are  those  invoked  by  the  infix  binary  operators  +,  *, 
and  /,  respectively.  They  normally  are  functions  that  take  any 
combination  of  integer  and  real  arguments,  but  here  we  redefine 
them  as  follows; 

rEAL<— 1 
VAK[ABLE<— 3 
STRUCT< — 4 

$P0RMULA(X,Y,Z)RS5 
[1]  R<— MKSTR(LP;X,0PJY,RP:Z) 

$ 


$SADD(X,Y)Z55 

(X=0.0)-»-ll 

(y»=o.oW9 

(ilk(x)=real)->6 

Z<— FORMULA (X,"+"  ,Y) 

->12 

(lLK(Y)=t=REAL)->4 

Z<— rplus(x,y) 

->12 


9J  Z<~-X 
10]  ->12 
11]  Z<— Y 


$ 
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1 

2 

3] 

4‘ 

5 

6 

7 

8] 


$SSUB(X,Y)Z55 

;y=o.o)->5 

(lLK(x)=REAL)->7 
Z  <-- .PORMUL A  ( X  ,  Y ) 

■♦9 

Z<— X 
■^9 

(lLK(Y)=t=REALK3 
z<— rsub(x,y) 

$ 


1] 


1] 

9] 

10 

11' 

12 

13] 

14] 

15] 


ISMUL(X,Y)Z55 
Y=1.0H12 
X=1.0H10 
X=O.OH8 

y=o.o)->8 
ILK(x)=REAL)h«i4 
z<— pormula(x,"x"  ,y) 
->16 

Z<— 0.0 
-»-l6 
Z<— Y 
-»16 
Z<— X 
->i6 

(ilk(y)^real)->6 
z<— rmult(x,y) 

$ 


1 

2 

3] 


4 

5] 

6~ 

7 

8 

9] 

10] 


3SDIV(X,Y)Zj5 

Y=1.0)->8 


X=0.0)->6 
ilk(x)=real)^io 

Z<~PORMUL A  ( X  ,  "  /  "  ,  Y  ) 

->12 

Z<— 0.0 
^12 
Z<— X 
->12 

(lLK(Y)fREAL)^4 

11]  z<— rdiv(x,y) 

$ 


We  now  define  recursive  functions  which  output  formulas,  differ¬ 
entiate  them  and  substitute  formulas  for  variables  in  other  formulas. 
Examples  of  output  follow  the  definitions. 


[1] 

[2] 

W 

[5J 

16] 

[7] 

[8] 


$PRINT(X)s? 

(ilk(x)=struct)->4 

type(x) 


-»9 

typeC'C) 

PRINT(X[LP]) 

TyPE(X[OP]) 

PRINT(X[RP]) 

.jypE('i)ft) 

$ 


") 


$SH0W(X)55 

[1]  print(x) 

[2]  typeC’ 


1 

2 

3] 

4' 

5 

6 


9 

10 

11 
12 
13] 
14 

15] 
16  ‘ 


19 

20 
21 
22 


$DERIV(E,X)R5UDASH,VDASH; 

'lLK(X)=t=VARIABLE  )^23 
{e=X)-»20 

(ILK(E)=STRLJCT)*>5 

->•22 

U DASH<— DERIV  ( E  [  LP  ]  , X  ) 

VDASH<— DERIV(e[RP],X) 

[E[  OP  ]="  +  '' )^12 
E[0P]="-" )^14 

’e[op]="/"  )->l6 

.E[0P]="x")->-18 

->23 

R<__UDASH-fVDASH 

->23 

R<— UDASH-VDASH 

->23 

R<—  (  (UDASHXE[  RP  ]  )-VDASHxE [  LP  ]  )/E[  RP  ]xE[  RP  ] 

->23 

R<— ( UDASHXE [ RP ] )+VDASHxE [ LP ] 

->23 

R<— 1 . 0 

^23 

R<— .0.0 

$ 
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$SUBST(E,X,A)R5S 
( ILK  ( X )  ^VARIABLE  )->9 
(ILK(e)4^TRUCT)^5 

R<— pormula(subst(e[lp],x,a),e[op],subst(e[rp],x,a)) 

**■9 

(E=X)^8 
R<— E 

•*•9 

R<— A 

$ 


F<— ("a"+"X'')/("B"+"X") 
show(deriv(f/'x"  )) 

(((B+X)-(A+X))/((B+X)x(BfX))) 

Q<_-PXF 

SHOW(Q) 

(  ( ( ( {BfX)-(  A+X)  )/U^xfx(&fX)  )  )x(  ( A+X)/(BfX) ))+(((  (B+X)-(A+X)  )/(  (B+X)x 
(B+-X)))x((A+X)/(BfX)))) 

SHOW  ( SUBST  ( P /' A"  .  F ) ) 

((((A+X)/(B+-X))+X)/(BfX)) 
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E  Vectors 


In  this  extension  we  define  functions  that  do  arithmetic  with 


3-vectors,  where 


3- vector  =  struct  (itarith,  jtarith,  krarith) 


Arith  =  real  or  integer. 


The  infix  arithmetic  operators  are  redefined  to  accept  arguments 


that  are  any  combination  of  arith  and  3-vector  and  to  produce  appro¬ 


priate  results.  Par  and  perp  are  predicates  that  test  whether  a 


pair  of  vectors  are,  respectively,  parallel  or  perpendicular.  The 


definitions  and  some  results  are  as  follows: 


$VECTOR(A,B,C)R55 
[1]  R<— MKSTR(l;A,JtB,KtC) 

$ 

ADD<~SADD 
SUB<— SSUB 
MUL<— SMUL 
EQ<~EQUAL 

$SADD(X,Y)RS5 
[1]  R<— OP(X,Y,ADD) 

$ 


$SSUB(X,Y)R55 
[1]  R<— OP(X,Y,SUB) 

$ 


1 
2 

3 

4 

[5 

[6 

lo] 


$OP(X,Y,Z)R;L; 

IlLK(_xjj4j-  - 


(ILK(Y, 


K7 

.  . 

R<— VEC10R(Z(X[l],Y[l]),Z(X[J],Y[Jj),Z(X[Kj,Y[K])) 

->11 

y<_-VECTOR(Y,Y,Y) 

•^3 

(lLK(Y)=t=4)->10 
X<— VECTOR(X,X,X) 

^3 

R<— Z(X,Y) 

$ 
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1 

2 

3] 

4‘ 

5 


$EQUAL(X,Y)R55 

(lLK(xj4=4)^5 

(iLk{y)+4)-»>5 

R^— (x[l]=y[l])x(X[j]=Y[J])x(X[K]=Y[K]) 
->6 

R<— EQ(X,Y) 

$ 


1 
2 
[3 

4 

5 

6 

[7J 

"8‘ 

[9] 

10 

11 

[12] 

[13] 


$SMUL(X,Y)R?C1,C2,C35 

;ilk(x)+4)-^io 

(lK(Y):i=4)H-8 

Cl<— (X[J]xY[K])-X[K]xY[J] 

C2<—  (X[  K]XY[  I  ]  )-X[  I  ]XY[K] 

C3<— (X[I]XY[  Jj)-X[J]xY[l] 
r<»»VECTOR(C1,C2,C3) 

->14 

r<»_VECTOR(X[I]xY,X[J]xY,X[K]xY) 

->l4 

(ILK(Y)  ={=4)^13 

r<_-VECT0R(XxY[I ] ,XxY[ J ] ,XxY[K ] ) 

■^►14 

R<— MUL(X,Y) 

$ 


") 


1 
2 

[5] 

6 

9] 

10] 
[11] 


$SH0W(X)55 
TYPE(X[I]) 
TYPE ("I") 
IFLJM(5,X[J]) 
TYPE(''+"  ) 
type(x[j  J) 
type("j") 

IFLJM(9,X[K]) 
TYPE 
TYPE 
TYPE 
TYPEI 

$ 


$D0T(X,Y)R5  5 

[1]  R<— (X[I]XY[I])+(X[  J]XY[J])+X[K]xY[K] 

$ 


$PERP(X,Y)RS5 
[1]  R<— ZER0(D0T(X,Y)) 

•  •  $ 
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$par(x,y)r;l; 

[1]  L<— .XxY 

[2]  R<--ZERO(L[l])xZERO(L[j])xZERO(L[K]) 

I 


$ZER0(X)R;5 

[1]  R<— (X=0)+(X=0.0) 

$ 


R<— VECT0R(1,2,5) 
S<— VECT0R(2,-3,7) 
SHOW(R) 

1I+2J+5K 

SHOW(S) 

2I-3J+7K 

SHOW(R+S) 

3I-1J+12K 

SHOW(RxS) 
29I+3J-7K  , 

DOT(R,S) 

31 

PERP(R,S) 

0 

PAR(R,S) 


0 


T<— 2xR 
SHOW(T) 
2I+4J+10K 

PAR(R,T) 

1 

PERP(R,RXS) 


1 

SH0W(4+R) 

5I+6J+9K 

SHOW(R+3) 

4I+5J+8K 
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F  Trees  and  Syntax 

In  this  extension  we  create  trees  and  use  them  in  various 
syntax  manipulations.  A  tree  is  defined  by 

Tree  =  struct  (fatherrptr,  rightbrother:ptr ,  firstsonrptr, 
valueratom) 

Ptr  =  NIL  or,  pointer 

Pointer  =  ref(tree) 

Atom  =  literal  or  integer  or  real  or  NIL. 

First  we  redefine  the  infix  binary  operators  so  that  they  will  create 
trees,  i.  e.  ,  so  that  a  a  b  (where  a  is  a  binary  operator)  is  a  tree 
whose  value  is  a,  whose  rightbrother  and  father  are  NIL,  and  whose 
firstson  is  a  tree  with  value  =  a,  father  =  a  a  b,  firstson  =  NIL,  and 
rightbrother  =  a  tree  with  value  =  b,  rightbrother  and  firstson  =  NIL, 
and  father  =  a  a  b.  This  is  an  instance  of  the  use  of  ref 's  to  share 
data  since  the  node  with  v'alue  a  is  shared  as  father  by  each  of  its 
sons.  This  representation  of  a  tree  with  three  links  associated  with 
each  node  is  that  suggested  by  Cheatham  in  [7]. 

$SADD(X,Y)RJ5 
[1]  R<— OPER(X,Y,"+") 

$ 

$SSUB(X,Y)R55 
[1]  R<— OPER(X,Y,"-") 

$ 

$SMUL(X,Y)R55 
[IJ  R<— OPER(X,Y,"x") 

$ 

$sdiv(x,y)r;5 
[1]  R<— OPER(X,Y,"/") 

$ 
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$oper{a,b.c)r;5 

;iLK(A)=f4W8 

(iLK(B)^=4)^10 

A  [  RIGHTBROTHER  ]<~MKREF  ( B ) 

R<— MKSTR( FAIHE R: NIL ,  RIGHTBRO IHER : N IL , FI RSTSON  : MKREF  ( A ) , VALUE  t  C ) 
A  [  FAIHE  R  ]<~MKREF  ( R ) 

B  [  FAIHER  ]  <— MKREF  (  R) 

->12 

A<— MKSTR  ( FATHER ;  NIL  ,  RI GHTBROTHE  Rt  NIL ,  FIRSTSON !  N  IL  ,  VALUE  t  A ) 

->2 

B<— MKSTR(FATHER:NIL,RIGHTBR0THER:NIL,FIRSTS0N:NIL,VALUE:B) 

*^3 

$ 


The  problem  of  how  to  output  the  constructed  structure  is 
somewhat  more  difficult  in  this  than  in  the  previous  extensions  given, 
particularly  since  a  tree  is  an  inherently  two-dimensional  object 
and  we  wish  to  display  it  in  a  linear  medium.  There  are  several 
standard  ways  of  doing  this,  all  involving  the  traversal  of  the  nodes 
in  some  specified  order.  We  show  three  typical  ones.  In  prefix 
walk  order  we  start  at  the  roots  of  the  tree  and  at  each  step  go  to 

(1)  the  firstson  of  the  current  node  if  there  is  one  or 

(2)  the  rightbrother  if  there  is  no  firstson  (in  general,  the 
right  neighbor  -  the  rightbrother  of  the  closest  ancestor 
who  has  a  rightbrother). 

In  suffix  walk  order,  we  traverse  terminal  nodes  in  left  to  right  order, 
always  traversing  an  interior  node  as  soon  as  we  have  encountered  all 
of  its  sons.  Finally,  in  constant  depth  walk  order,  we  traverse  first 
the  root,  then  all  sons  at  depth  two,  and  so  on.  The  prefix  and  suffix 
functions  use  explicit  recursion  to  traverse  subtrees,  whereas  the 
constant  depth  function  uses  a  push  down  stack,  i.  e.  ,  a  datum  defined 
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by 


Stack  =  struct  (stkti'owlOO,  level; integer) 
RowlOO  =  seq  ( 100), 


Output  obtained  with  these  functions  follows  their  definitions. 


[1] 

[2] 


$SH0WPREFIX(X)55 

SHOWP(X) 

TXPE  ( '' 

$ 


$SHOWP(X)5L; 

TYPE  (X[  VALUE]) 

(X[FIRSTS0N]=NIL)->11 

TyPE("('') 

L<— VLPTR  ( X  [  F  IRS  TSON  ] ) 
SHOWP(L) 

( L  [  RIGHTBROIHER  ]=NIL)^10 
TyPE(",") 

L<— VLPTR(L[  RIGHTBROTHER  j ) 

TYPE(")") 

$ 


$SHOWS(a)5LJ 

( A[  FIRSTSON  J  =NIL  )-»lO 

TYPE("(") 

L<— VLPTR  ( A[  FIRSTSON  ] ) 
SHOWS[L) 

( L  [  RIGH  TBROTHER  ]  =NIL  )->9 
TypeC',") 

L<— VLPTR(L[  RIGHTBROTHER] ) 
">’4 

TYPE("}") 

TYPE  (a[  VALUE]) 

$ 


$SHOWSUFFIX(a)5S 

[1]  SHOWS (a) 

[2]  typeC' 
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Llj 

2] 

3] 

4] 

3] 

[6j 

7] 

8] 

9] 


10' 

11' 

12' 

13; 

i4; 

15] 


19; 

20] 


$SH0WCD(a)sX,I5 

S1<--MKSTR(STK?MKNHa/ ( 50 ) ,  LEVEL  8  0  ) 
PUSH  ( MKREP  { SI )  ,  MK  REF  ( A  )  j 
S  2<— MKSTR  (  STKt  MKNRV/  (  50  )  ,  LEVEL  8  0  ) 
ASIGN(I,1>TYPE("(")) 

X<— VLPTR ( SI  [  STK  J  ( I ) ) 

TYPE?"  ") 

TYPE  (X[  VALUE]) 

(X[FIRSTS0N  ]=NIL)*»10 
PUSH  (MKREF  { S2) , X [  FIRSTSON  ] ) 

(X[  RIGHTBR0'IHER]=NIL)->13 
X<— VLPTR  (X[  RIGHTBROIHER  ] ) 

->D 

(I=S1[  LEVEL  ])->-l6 
I<— IPLUS(I,1) 

-*’5 

TYPE(")") 

(S2[LEVEL]=0)^21 
Si<— S2 
S2[LEVEL]<— 0 
->4 

$ 


$SHOWCONSTANTDEPTH ( A ) 5  5 

[1]  showcd(a) 

[2]  TYPE(" 

") 

$ 


$PUSH(X,Y)S5 

[  1  ]  VL  PTR  (  X  )  [  LEVEL  ]  <~VL  P  TR  ( X  )  [  LEVEL  ]  +1 
[2]  VLPTR(x)  [STK]  (VLPTR(X)  [LEVEL]  )<—Y 

$ 
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Y<— (3+7)-(4x8)/5 
showprefix(y) 

-(+{3,7),/(x(4,8),5)j 

showsuffix(y) 

((3,7)+,((4,8)x,5)/)- 

SHO WCON  STANTDE  PTH  ( Y ) 

{  -)(  +  /)(  3  7  X  5)(  4  8) 

A<— Y+Y 

showprepix(a) 

+(-(+(3,7),/(x(4,8),5)),-(+(3,7),/(x(4,8),5))) 

SHOWCONSTANTDEPTH ( A ) 

(  +)(  .  -)(+  /  +  /)(  3  7  X  5  3  7  X  5)(  4  8  4  8) 

showsuffix(a) 

(((3,7)+,((4,8)x,5)/)-,((3,7)+,((4,8)x,5)/)-)+ 
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A  major  application  of  the  data  type  tree  occurs  in  the  prob¬ 
lem  of  parsing  a  sentence  generated  by  a  general  context  free  gram¬ 
mar.  Rather  than  show  functions  which  solve  this  general  problem, 
we  develop  routines  which  parse  a  sentence  in  a  context  free  grammar 
which  is  simple  precedence  with  f  and  g  functions  (qv.  [?]).  The 
variable  grammar  is  a  representation  of  a  simple  precedence  gram¬ 
mar,  namely 

S  ::=  E  RPAD 
E  ::=  E+T 
E  ::=  T 
T  ::=  A 
T  ::=  AT 

The  first  rule  is  not  included  in  the  representation,  since  it  is  rec¬ 
ognized  "by  hand"  by  the  functions  we  define.  Parse  employs  a 
push  down  stack  to  save  the  fragments  of  the  parse  tree  constructed 
at  some  stage  in  a  parse,  and  uses  the  f  and  g  functions  to  decide 
when  to  make  a  reduction.  Match  makes  reductions,  recognizing 
the  rule  to  be  used,  and  growing  the  appropriate  piece  of  tree.  When 
parse  sees  the  right  pad  symbol,  it  constructs  the  final  tree  fragment  - 
the  root  node,  and  returns  this  as  result.  The  functions  and  some 
typical  output  are: 
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1’ 

'2 

[3] 

[^] 

[5] 

[6] 

.9] 

10’ 

11' 

12; 

[13] 

14' 

[15] 

[16] 

ill] 

[19] 


$PARSE(X,GR,F,G)R;Z,RR,X1,IJ 
Z<— MKSTR ( STK  t  MKNRV ( 50 ) , LEVEL : 0 ) 

RR<— MKREP(Z) 

ASGNC(X1,VLPTR(X)) 

PUSH(RR,MKREF(N0DE(NIL,NIL,NIL,X1(1) ) ) ) 

I<— 2 

(F (VLPTR(Z [ STK  ]  (Z [LEVEL ])) [VALUE ] )-G(Xl( I )) )^li 
PUSH (RR,MKREF(N0DE(NIL, NIL, NIL, X1(I) ))) 

(X1(I)="  RPAD"  )-»-13 
I^— I+l 
■^6 

MATCH (RR,GR) 

->6 

I<— 1 

VLPTR ( Z [ STK ] ( I ) } [ RIGHTBROTHE  R] <— Z [ STK ] ( I+l ) 
VLPTR(z [  STK  ]  ( I ) )  [ FATHER ]<— MKREF ( r) 

I<— I+l 

(l^[  LEVEL]  )^14 

R<— N0DE(NIL,NIL,Z[STK](1),"S") 

VLPTR(Z  [  STK  ](!))[  FATHER  ]<— MKREF  (  R) 

$ 


1' 

2 

[3] 

[4] 

[5] 

[6] 

[7] 

[8] 

[9] 

10' 

11; 

12; 

[13] 


14 

15 

16 


'21' 

^22; 


$MATCH(RR,GR)5I,M,Z,J,K,N,S,T5 
I<— 1 

ASGNC(T,VLPTR(GR)) 

asgnc(z,vlptr(rr)) 

J<— LNG‘IH(T(I)[RP]) 

K<— J 

N<— Z[  LEVEL  ]+K-J 
N->10 


I<— I+l 
•>4 

(T(I)  [RP  ]  (K)=VLPTR(Z[STK]  (N)  )  [VALUE]  )->12 
->8 


K<~K-  1 
K->6 

EQUAL  (M<—N,M,Z 

vlptr(z[stk](m} 

vlptr(z[stk](m) 


LEVEL  ]  )-»'19 
■FA'IHER]<— MKREF  (S) 

■  RIGHTBRO  THER  ]<— Z  [  STK  ]  ( M+1 ) 


M<— M+1 

(M4=Z  [LEVEL  ])->15 

VLPTR( Z [ STK]  ( M )  )  [  FATHER ]<— MKREF ( S ) 

Z  [  LEVEL  ]<—N 

s<— node(nil,nil,z[stk](n),t(i)[lp]) 

Z  [  STK  ]  (N  )<— MKREF  ( S ) 

$ 
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$NODE(a,B,C,D)R55 

[  1  ]  R< — MKSTR  (FATHER?  A ,  RIGHTBROTHER?  B,  FIRSTSON  ?  C ,  VALUE  ?  D  ) 

$ 


$F(X)RJ5 

[IJ  EQUAL(X,"S"  ,R<— 0)->7 

[2]  equal{x,”e",r<— 0)->7 

[3]  equal(x,''t",r<— l)->7 

[4]  equal(x,"a",r<— lj->7 

[5]  equal{x,"+",r<— o)->7 

[6]  EQUAL (x,"RP AD"  ,R<—0)->7 

$ 


[1. 

[2] 

[3] 

[4' 

[5. 

[6] 


$G(x)R55 

EQU  AL  ( X  ,  "  S  "  ,  R<— 0  )->7 
EQUAL  ( X , "  E  "  ,  R<— .0  ]->7 
EQUAL  ( X  ,  "  T"  ,  R<— 1  )->7 
EQU  AL  ( X  ,  "  A  "  ,  R<—  2  )->7 
EQUAL  ( X  R<—0  )-J>7 

EQUAL (X,"RP AD"  ,R<— 0)->7 
$ 


RULE1<— MKSTR (LP  ?  "  E"  ,  RP  ?MKROW  ( "E"  ,  "  +"  ,  "  T"  )  ) 


II  ^11  II 

"t"5) 

"a")) 


II T-' 5) 


RULE2<— MKSTR (LP:"T"  ,RP:MKroWI 
RULE  3<— MKSTR!  LP  ? "  E "  ,  RP :  MKROW I 
RULE4<— MKSTR  ( LP  :  "  T"  ,  RP  :  MKROW  I 
GRAMMAR<—MKREF( MKROW  (  RULEl ,  RULE2,  RULE3 , RULE4)  ) 
X<—MKREF  (MKROW  ( "  A"  ,  "  A"  ,  "+"  ,  "  A"  ,  "+"  ,  "  A"  ,  "  RPAD*'  )  ) 
Y<— PARSE  (X,  GRAMM  AR,F,g) 

SHOWPREFIX(Y) 

s(e(e(e(t(a,t(a))),+.t(a)),+,t(a)),rpad) 

showsuppix(y) 

(((((a,(a)t)t)e,+,(a)t)e,+,(a)t)e,rpad)s 

SHOW CON STANTDEPTH (Y ) 

(  S)(  E  rpad)(  e  +  t)(  e  +  t  a)(  t  a)(  a  t)(  a) 


-56- 


G  Complex  and  Rational  Arithmetic 

In  this  extension  we  redefine  the. arithmetic  operators  to 
accept  arguments  that  are  a  pair  of  complex  numbers  (complex  = 
struct  (rp;real  ,  iptreal,  type:"comp"))  or  a  pair  of  rationals  (rational 
struct(num: integer,  den:integer, type: "ratio"))  as  well  as  the  atomic 
arguments  they  previously  accepted.  Complex  is  the  constructor 
for  complex  numbers  and  SDIV  constructs  rationals  when  called 
with  a  pair  of  integer  operands.  Hence  the  infix  operator  "/"  acts 
sometimes  as  a  constructor  and  sometimes  as  a  normal  divide  op¬ 
erator.  We  note  that  the  rational  constructor  function  always  pro¬ 
duces  a  rational  whose  num  and  den  components  are  coprime,  using 
the  gcd  (greatest  common  divisor)  function  to  this  end.  The  func¬ 
tions  and  some  output  produced  by  them  are  as  follows: 


DIV<— SDIV 
MUL<~SMUL 
ADD<— SADD 
SUB<— SSUB 

$C0MPLEX(A,B)R;5 

[  1  ]  R<~MKSTR ( RP  J  A ,  IP  :  B ,  TYP E  8  "  COM P "  ) 

$ 


$RATI0(A,B)R5GS 
G<— GCD(A,B) 

R<— MKS TR  ( NUM  8 IDIV  (  A  ,  G  )  ,  DEN  8 1 DIV  ( B ,  G  )  ,  TYPE  8 

$ 


"RATIO") 
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1 

[2. 

3J 

4‘ 

5] 

6 


I 


9_ 
[10] 
11] 
12] 


5SDIV(A,B)R5D; 

(ILK(a)=2)x(ILK(B)=2))h-7 

ilk(a)=i)->5 

A[IYPE]=''C0MP”  K9 
[A[1YPE]=" RATIO"  )->12 
R<— DIV(A,B) 

^13 

R< — ratio  ( A,  B) 

-►13 

EK— (B[RP]xBfRP])+B[lP  ]xB[IP] 

R<— COMPLEX(  ( { X[ IP ]XY[  IP ]  )+X[  RP  ]XY[  RP ]  )/D,  ( (X [ IP  ]XY[  RP  ]  )-X [RP  ]XY[  IP  ]  )/D) 

-►13 

R< — ( A[ NUM]xB[ DEN ] )/a[ DEN ]xB[NUM ] 

$ 


$SMUL(A.B)R$5 
{(ILK(a)=1)+ILK(a)=2)->4 
(a[TYPE]="C0MP")->8 
(a[TYPE  1="  RATIO 
R<— MUL(A,B) 

-*9 

R<—  ( A[  NUM  ]XB[ NUM  ]  )/a[  EEN  ]xB[DEN  ] 

■►9 

R<— COMPLEX  ( ( A[ RP ]xB[ RP  ]  )-A[  IP  ]xB[  IP  ] ,  ( A[  RP  ]xB[  IP  ]  )+A[  IP  ]xB[ RP  ]  ) 

$ 


2] 


i] 

1] 

7] 


$SADD(A,B)RtCRPR,G5 

iplus(ilk(a)=i,ilk(a)=2)- 

(A[  TYPE  ]= ''COMP"  )->9 

(a[type]="ratio''  )^6 

R<— ADD(A,B) 


-►10 

CRPR<— ( A [  NUM  ]XB[  DEN  ]  ) +A  [  DEN  ] XB  [NUM  ] 
R<— CRP  ^A  [  DEN  ]  xB  [  DEN  ] 

•>10 

R< — COMPLEX  ( A[  RP ]4-B[  RP  ] ,  A[  IP  ]+B [  IP  ] ) 
$ 
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$GCD(X,Y)R5S 

X-»-3 

X<— 0-X 
Y->5 

Y<— 0-Y 

EQU  AL  ( Y  ,1  ^  R<~1 

EQUAL  ( X ,  1  >  R<— 1  hl4 

equal{x,o  ,R<— y)-»'14 

EQU  AL  ( Y ,  0 ,  R<— X )  -^-14 

(X-Y)-»-12 

Y<— Y-X 

-►5 


X<— X-Y 
->5 


$ 


$PRINT(X)5t 

((lLK(x)=2)+(lLK(X)=3)hl2 
TYPE(X(i) ) 

(X[TYPE ]=" RATIO"  )^9 
IFLJM(6,X[IP]) 

TYPE  ('4"  ) 
type(x[ip]) 

TYPE ("I 

^13 

Type("/") 

X[DEN] 

■>13 

X 

$ 


j  III  iiuu 


A<— COMPLEX  ( 1 . 0 ,  -  2 . 5 
B<— COMPLEX  (3 . 0 , 4 . 0 ) 

print(a) 


1.0-2.51 

PRINT(B) 

3.0+4.01 

print(a+b) 


4.0+1.51 

PRINT{AxB) 

1.3E1-3.5I 

print(a/b) 


-2.8E-1-4.6E-1I 


8/21 

6/7 

29/14 

4/1 


A<~4/7 
B<— 3/2 
PRINT (a/B) 

PRINT (AxB) 

PRINT (A+B) 


C<— 24/7 
print(a+c) 


) 
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2 

3] 
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5 

6 

[7 

‘8 


H.  Block  Structure  and  Own  Variables 

The  next  extension  we  describe  is  not  implemented  in  the 
current  version  of  CEL  (though  the  additions  to  the  current  CEL  that 
are  necessary  to  make  it  implementable  are  straightforward).  The 
base  language  of  CEL  has  only  two  levels  of  block  structure  -  vari¬ 
ables  are  either  global  or  local  to  a  function.  The  following  extension 
would  add  multilevel  block  structure  and  scoping  of  variables  (in  the 
ALGOL  sense). 

The  primary  data  structure  that  we  use  is  an  environment, 
defined  as  follows: 

Env  =  struct(father: block,  current: struct) 

Block  =  NIL  0£  env. 

We  note  that  the  type  of  env[current]  is  not  completely  specified. 

This  is  convenient  in  view  of  the  way  data  of  type  env  are  to  be  con¬ 
structed  and  is  made  possible  by  the  absence  of  declarations  in  CEL. 
We  first  define  functions  that  open  and  close  blocks  and  decide  which 
variable  an  identifier  refers  to  in  a  particular  environment. 

$BEGIN(L)?I/X; 

I<_-LNGTH(Lj 

x<— mknst(i) 

J<— 1 

name(x(j),l(j)) 

J<— J+1 
*►4 

CURRENT<— MKREF  ( MKS TR  ( PAIHER:  CURRENT ,  CURRENT : X ) ) 

$ 


$END()55 

[  1  ]  CURRENT<— VL  PTR  ( CURRENT )  [  F  ATHE  R  ] 

$ 
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$SELECT(a)R5L5 
L<— CURRENT 

ELEMENT(A,VLPTR(L)  [CURRENT  ])->? 
(vlptr(l)  [father  3  =nil)^6 

L<— VLPTR(L )  [ FATHER ] 

^2 

ERROR( ) 

r<_-VLPTR  ( L  )  [  CURRENT  J  A  3 

$ 


The  argument  to  begin  is  a  row  of  the  identifiers  to  be  local  to  the 
block  being  opened.  The  unimplemented  (as  yet)  library  function 
MKNST  creates  a  struct,  x,  whose  length  is  the  number  of  local  iden¬ 
tifiers.  The  library  function  NAME  then  attaches  the  names  of  the 
elements  of  1  to  the  components  of  x.  Finally,  the  environment  thus 
created  is  made  the  current  environment  with,  as  father,  the  previous 
environment.  End  simply  transforms  the  current  environment  to  the 
previous  one.  Select,  given  an  identifier,  finds  the  version  of  it  whose 
scope  includes  the  current  block  using  the  (currently  unimplemented) 
library  function  ELEMENT  which  determines  whether  a  struct  has 
a  component  with  a  specified  name.  One  presumes  that  this  extension 
would  be  used  in  conjunction  with  a  syntax  mapper  in  which  <identifiei> 
was  converted  to  the  equivalent  in  the  base  syntax  of  select  (<ident- 
ifiei>).  We  note  that  we  can  easily  adjust  this  extension,  by  making 
‘current*  an  argument  to  begin,  end  and  select,  so  that  we  can  deal 
with  multiple  parallel  environments. 
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We  can  use  a  similar  technique  to  obtain  the  effect  of  own 
variables,  i.  e.  ,  variables  local  to  a  function  whose  lifetime  properly 
contains  the  time  during  which  the  function  is  being  executed.  To  do 
this  we  define  a  data  type 

funcwithowns  =  struct(func;function,  vars; struct). 

Now  we  must  define  a  function  that  is  to  take  own  variables  with  a 
header  such  as  "$f(x)  ...  "  where  x  is  a  struct  whose  component 

names  are  those  of  the  formal  parameters  and  own  variables  of  f. 
Within  f,  we  use  a  mechanism  like  the  function  select  (but  simpler, 

since  environments  are  not  nested)  to  get  at  the  parameters  and  own 
variables  of  f.  To  call  f,  we  write  "call(fprime, x^^, .  .  .  where 

the  xj  are  the  arguments  to  f,  fprime  =  struct(func;f,  owns;b),  and 
the  syntax  mapper  transforms  ''call(fprime,  x^  .  .  .  to 

f(fprime[vars])  and  sets  the  components  of  fprime[vars]  correspond¬ 
ing  to  arguments  appropriately. 
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SECTION  VII 


The  Implementation  of  CEL 

CEL  is  currently  implemented  in  approximately  two  thousand 
lines  of  code  on  a  Digital  Equipment  Corporation  PDP-10  Computer, 
a  one-address  machine  with  sixteen  accumulators  and  a  sizeable  in¬ 
struction  set.  The  implementation  provides  the  facilities  described 
above  via  several  data  structures.  Of  particular  interest  are  a  pair 
of  push  down  stacks  which  are  used  to  drive  program  execution  and  a 
large  data  area  which  contains  all  linked  structures  used  -  including 
all  program  variables  as  well  as  program  text.  This  space  is  garbage 
collected  by  means  of  a  modification  of  the  algorithm  described  by 
Schorr  and  Waite  in  [25]  (see  also  [17],  p.  417). 

We  hope,  as  noted  previously,  to  make  several  eventual 
improvements  in  this  implementation.  In  particular,  we  plan  to  include 
a  Brooker  and  Morris -like  syntax  definition  mechanism  and  text  editing 
and  debugging  facilities  like  those  of  APL.  Some  less  important  changes 
are  also  intended,  including  the  addition  of  a  number  of  new  library 
functions  and  the  improvement  of  the  storage  management  algorithms 
currently  in  use. 
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SECTION  vm 


Conclusions 

We  hope  that  it  is  clear  from  the  examples  given  above 
that  extensible  languages  in  general,  and  CEL  in  particular,  provide 
mechanisms  that  make  it  possible  to  deal  conveniently  with  many  diverse 
problem  areas.  We  note  that  each  of  the  examples  of  Section  VI  was 
coded  and  debugged  in  less  than  a  day’s  time  (often  a  good  deal  less). 

By  contrast,  the  implementers  of  FORMULA  ALGOL  required  eight 
man  years  to  produce  a  system  containing  these  facilities  [32],  We 
do  not  have  enough  experience  with  programming  in  extensible  languages 
to  provide  a  basis  for  comparing  their  practical  utility  with  that  of 
the  shell  and  special  purpose  languages,  particularly  in  large  appli¬ 
cations.  But  we  can  point  to  the  relative  ease  of  implementing  exten¬ 
sible  languages  and  programming  in  them  (especially  when  conver¬ 
sational  features  are  included)  as  very  significant  advantages  of  ex¬ 
tensible  languages.  Even  where  object  program  efficiency  is  an  important 
consideration,  it  may  often  turn  out  that  a  compilation  facility  (together 
with  optional  declarations  in  a  typeless  language)  will  make  object 
program  efficiency  quite  adequate. 


-65- 


Appendix  A 

Library  Functions  of  CEL 


The  following  library  functions  are  included  in  CEL's  cur¬ 
rent  implementation: 

1.  ASGNC  (respectively  ASIGN)  takes  two  arguments  and  sets  the 
value  of  the  first  as  the  second  (respectively  a  copy  of  the  second), 
ASIGN  is  invoked  by  the  infix  operator 

2.  BRNCH,  if  called  with  two  arguments  x  and  y  is  equivalent  to 
IFGJM(y,x);  if  called  with  one  argument  x  it  is  equivalent  to  GOTO. 
It  is  invoked  by  the  infix  operator- ->. 

3.  EQUAL(x,y)  =  if  x  is  the  same  as  y  in  value  and  type  then  1  and 
otherwise  0.  It  is  invoked  by  the  infix  operator  = 

4.  GOTO  takes  a  single  integer  argument  and  sets  the  program  counter 
to  the  value  of  this  argument. 

5.  IDIV  (respectively  IMULT,  IPLUS,  ISUB)  takes  two  integer  argu¬ 
ments  X  and  y  and  returns  [x^-y]  (respectively  the  product,  sum, 
difference  of  x  and  y). 

6.  IFGJM  (respectively  IFLJM,  IFZJM)  takes  two  integer  arguments 
and  sets  the  value  of  the  program  counter  as  the  first  if  the  second 
is  positive  (respectively  negative,  zero). 

7.  ILK(x)  returns  an  integer  code  for  the  type  of  x  as  follows: 


NIL  0 

real  1 

integer  2 

literal  3 

struct  4 

ref  5 
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row 

oref 

identifier 

delimiter 
code  string  pair 
defined  function 
library  function 
packed  identifiers 
statement 
locked  function 


6 

7 


8 


9 

10 

11 

12 

13 

14 

15 


8.  LNGTH  takes  a  single  row  or  struct  argument  and  returns  its 
length. 

9.  MKNRW(n),  n  a  positive  integer,  returns  a  row  x  of  length  n  sat¬ 
isfying  (Vl<i^n)  (x(i)  =  NIL) 

10.  MKREF{x)  returns  a  pointer  to  x. 

11.  MKROW  takes  an  arbitrary  positive  number  of  arguments  and  re¬ 
turns  a  row  (whose  length  is  the  number  of  arguments)  of  copies 
of  their  values. 

12.  MKSTR  takes  a  set  of  arguments  {  L^:  i  r^O  ,  and  returns  a 

struct  X  of  length  n  whose  i^^  component  is  named  Lj  and  has  as 
value  a  copy  of  Vj. 

13.  NOTEQ(x,  y)  =  if  x  is  the  same  as  y  in  value  and  type  then  0  and 
otherwise  1.  R  is  invoked  by  the  infix  operator  :|=  .  . 

14.  RDIV  (respectively  RMULT,  RPLUS,  RSUB)  takes  two  real  argu¬ 
ments  and  returns  their  quotient  (respectively  product,  sum,  differ¬ 
ence). 

15.  SDIV  (respectively  SMUL,  SPLITS,  SSUB)  takes  two  real  or  integer 
arguments,  converts  the  second  to  the  type  of  the  first  and  invokes 
IDIV  or  RDIV  (respectively  IMUL  or  RMUL,  IPLUS  or  RPLUS, 

ISUB  or  SSUB)  as  appropriate  to  do  the  calculation.  It  is  invoked 
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by  the  infix  binary  operator  /  (respectively  +,  -). 

16.  TYPE  takes  a  single  argument  and  outputs  it  to  the  user's 
teletype  if  it  is  real,  integer  or  literal . 

17.  VLPTR(x)  returns,  for  x  a  ref ,  the  datum  at  which  x  points. 
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Appendix  B 

F  and  G  Functions  and  Precedence  Matrix 
for  a  Front  End  Syntax  of  CEL 

G;  S  ::=  E  |  I;E 

E  ::=  T  a  E  I  a  E  |  T 
T  ;:=I|  C  I  (S)  I  T()  |  T(S,...,S)  \ 

g  1  3  3  1  3  3  3  1  3  3 
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language.  Its  syntax,  data,  control  structures  and  conversational 
features  are  presented  and  compared  to  those  of  other  languages. 
Its  use  is  illustrated  by  means  of  several  examples  in  the  areas  of 
list  processing,  polynomial  arithmetic,  formula  manipulation, 
vector  arithmetic,  trees  and  syntax  analysis,  complex  and 
rational  arithmetic  and  block  structure  and  own  variables. 
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